Improve WAL reliability documentation, and add more cross-references to it.

In particular, we are now more explicit about the fact that you may need
wal_sync_method=fsync_writethrough for crash-safety on some platforms,
including MaxOS X.  There's also now an explicit caution against assuming
that the default setting of wal_sync_method is either crash-safe or best
for performance.

2 files changed, 13 insertions, 4 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0075a1ee0d0..76af829d2d7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1459,7 +1459,11 @@ SET ENABLE_SEQSCAN TO OFF;
        <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.
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index c21e4a4d623..36545e4e1a5 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -75,7 +75,9 @@
    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>
@@ -481,8 +483,10 @@
    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 as far as reliability goes,
-   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>
@@ -542,6 +546,7 @@
    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>