Support syncing WAL log to disk using either fsync(), fdatasync(),

O_SYNC, or O_DSYNC (as available on a given platform).  Add GUC parameter
to control sync method.
Also, add defense to XLogWrite to prevent it from going nuts if passed
a target write position that's past the end of the buffers so far filled
by XLogInsert.

2 files changed, 39 insertions, 13 deletions

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index f321cea669b..f7b9f26f434 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.56 2001/03/13 01:17:05 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.57 2001/03/16 05:44:33 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -1224,8 +1224,8 @@ env PGOPTIONS='-c geqo=off' psql
       <term>WAL_BUFFERS (<type>integer</type>)</term>
       <listitem>
        <para>
-        Number of disk-page buffers for WAL log.  This option can only be set
-	at server start.
+        Number of disk-page buffers in shared memory for WAL log.
+	This option can only be set at server start.
        </para>
       </listitem>
      </varlistentry>
@@ -1250,6 +1250,23 @@ env PGOPTIONS='-c geqo=off' psql
        </para>
       </listitem>
      </varlistentry>
+
+     <varlistentry>
+      <term>WAL_SYNC_METHOD (<type>string</type>)</term>
+      <listitem>
+       <para>
+        Method used for forcing WAL updates out to disk.  Possible
+	values are
+	<literal>FSYNC</> (call fsync() at each commit),
+	<literal>FDATASYNC</> (call fdatasync() at each commit),
+	<literal>OPEN_SYNC</> (write WAL files with open() option O_SYNC), or
+	<literal>OPEN_DATASYNC</> (write WAL files with open() option O_DSYNC).
+	Not all of these choices are available on all platforms.
+        This option can only be set at server start or in the
+	<filename>postgresql.conf</filename> file.
+       </para>
+      </listitem>
+     </varlistentry>
     </variablelist>
     </para>
    </sect2>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index c92ccd9d230..69616409e81 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.4 2001/03/13 01:17:05 tgl Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.5 2001/03/16 05:44:33 tgl Exp $ -->
 
 <chapter id="wal">
  <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@@ -282,15 +282,6 @@
   </para>
 
   <para>
-   Setting the <varname>WAL_DEBUG</varname> parameter to any non-zero
-   value will result in each <function>LogInsert</function> and
-   <function>LogFlush</function> <acronym>WAL</acronym> call being
-   logged to standard error.  At present, it makes no difference what
-   the non-zero value is.  This option may be replaced by a more
-   general mechanism in the future.
-  </para>
-
-  <para>
    The <varname>COMMIT_DELAY</varname> parameter defines for how many
    microseconds the backend will sleep after writing a commit
    record to the log with <function>LogInsert</function> but before
@@ -304,6 +295,24 @@
    ten milliseconds, so that any nonzero <varname>COMMIT_DELAY</varname>
    setting between 1 and 10000 microseconds will have the same effect.
   </para>
+
+  <para>
+   The <varname>WAL_SYNC_METHOD</varname> parameter determines how
+   Postgres will ask the kernel to force WAL 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.
+   Note that this parameter is irrelevant if <varname>FSYNC</varname>
+   has been turned off.
+  </para>
+
+  <para>
+   Setting the <varname>WAL_DEBUG</varname> parameter to any non-zero
+   value will result in each <function>LogInsert</function> and
+   <function>LogFlush</function> <acronym>WAL</acronym> call being
+   logged to standard error.  At present, it makes no difference what
+   the non-zero value is.  This option may be replaced by a more
+   general mechanism in the future.
+  </para>
  </sect1>
 </chapter>