git.postgresql.org Git - postgresql.git/commitdiff

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml

index b904238800a5b1d54a52c2278e8263bf259b91a8..65ac6fc5d2dee557d61ef3924740e55abf7bd07e 100644 (file)

--- a/doc/src/sgml/config.sgml

+++ b/doc/src/sgml/config.sgml

</itemizedlist>

<para>

Not all of these choices are available on all platforms.

- The default is the first method in the above list that is supported

- by the platform. The default is not necessarily best; it may be

- necessary to change this setting, or other aspects of your system

- configuration, in order to create a crash-safe configuration, as

- discussed in <xref linkend="wal-reliability">, or to achieve best

- performance.

The <literal>open_</>* options also use <literal>O_DIRECT</> if available.

+ The default is the first method in the above list that is supported

+ by the platform. The default is not necessarily ideal; it might be

+ necessary to change this setting or other aspects of your system

+ configuration in order to create a crash-safe configuration or

+ achieve optimal performance.

+ These aspects are discussed in <xref linkend="wal-reliability">.

The utility <filename>src/tools/fsync</> in the PostgreSQL source tree

can do performance testing of various fsync methods.

This parameter can only be set in the <filename>postgresql.conf</>

diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml

index 757c884c87cfae442af4509209bacfa9f6ed0527..8d8504552d2fbcf3bad35702b3201a7d5c4d4996 100644 (file)

--- a/doc/src/sgml/wal.sgml

+++ b/doc/src/sgml/wal.sgml

<para>

The <xref linkend="guc-wal-sync-method"> parameter determines how

<productname>PostgreSQL</productname> will ask the kernel to force

- <acronym>WAL</acronym> updates out to disk.

- With the exception of <literal>fsync_writethrough</>, which can sometimes

- force a flush of the disk cache even when other options do not do so,

- all the options should be the same in terms of reliability.

- However, it's quite platform-specific which one will be the fastest.

+ <acronym>WAL</acronym> updates out to disk.

+ All the options should be the same in terms of reliability, with

+ the exception of <literal>fsync_writethrough</>, which can sometimes

+ force a flush of the disk cache even when other options do not do so.

+ However, it's quite platform-specific which one will be the fastest;

+ you can test option speeds using the utility <filename>src/tools/fsync</>

+ in the PostgreSQL source tree.

Note that this parameter is irrelevant if <varname>fsync</varname>

has been turned off.

</para>