index 39be6243cac0ad6ba08fc3f807f4562074b946f1..b904238800a5b1d54a52c2278e8263bf259b91a8 100644 (file)
<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.
+ 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 utility <filename>src/tools/fsync</> in the PostgreSQL source tree
can do performance testing of various fsync methods.
index 8a118cfece8a191b57e86ddc68de79ebc719db17..70fc832e23d8f11d844dca34974b9502fc3168e0 100644 (file)
by unchecking <literal>My Computer\Open\{select disk
drive}\Properties\Hardware\Properties\Policies\Enable write caching on
the disk</>. Also on Windows, <literal>fsync</> and
- <literal>fsync_writethrough</> never do write caching.
+ <literal>fsync_writethrough</> never do write caching. The
+ <literal>fsync_writethrough</> option can also be used to disable
+ write caching on <productname>MacOS X</>.
</para>
<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.
- All the options should be the same in terms of reliability,
- but it's quite platform-specific which one will be the fastest.
+ 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.
Note that this parameter is irrelevant if <varname>fsync</varname>
has been turned off.
</para>
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
<acronym>WAL</acronym> log files do not make such false reports.
+ (See <xref linkend="wal-reliability">.)
</para>
<para>