rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add mention of using tools/fsync to test fsync methods. Restructure 

recent wal_sync_method doc paragraph to be clearer.
This commit is contained in:
Bruce Momjian 2010-10-19 14:56:33 +00:00
parent 604ab08145
commit f75d6a1b19
2 changed files with 13 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/config.sgml
View File

@ -1569,13 +1569,13 @@ SET ENABLE_SEQSCAN TO OFF;
</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</>

12
doc/src/sgml/wal.sgml
View File

@ -530,11 +530,13 @@
<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>