Disable full_page_writes, because turning it off risks causing crash-recovery

failures even when the hardware and OS did nothing wrong.  Per recent analysis
of a problem report from Alex Bahdushka.

For the moment I've just diked out the test of the parameter, rather than
removing the GUC infrastructure and documentation, in case we conclude that
there's something salvageable there.  There seems no chance of it being
resurrected in the 8.1 branch though.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d564b14a5c2df9c682502b438ae88604490d35db..b617dfa814752b62494ff4da24c4ab75ef03640e 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1354,40 +1354,14 @@ SET ENABLE_SEQSCAN TO OFF;
         When this option is on, the <productname>PostgreSQL</> server
         writes the entire content of each disk page to WAL during the
         first modification of that page after a checkpoint.
-        This is needed because
-        a page write that is in process during an operating system crash might
-        be only partially completed, leading to an on-disk page
-        that contains a mix of old and new data.  The row-level change data
-        normally stored in WAL will not be enough to completely restore
-        such a page during post-crash recovery.  Storing the full page image
-        guarantees that the page can be correctly restored, but at a price
-        in increasing the amount of data that must be written to WAL.
-        (Because WAL replay always starts from a checkpoint, it is sufficient
-        to do this during the first change of each page after a checkpoint.
-        Therefore, one way to reduce the cost of full-page writes is to
-        increase the checkpoint interval parameters.)
        </para>
 
        <para>
-        Turning this option off speeds normal operation, but
-        might lead to a corrupt database after an operating system crash
-        or power failure. The risks are similar to turning off
-        <varname>fsync</>, though smaller.  It may be safe to turn off
-        this option if you have hardware (such as a battery-backed disk
-        controller) or filesystem software (e.g., Reiser4) that reduces
-        the risk of partial page writes to an acceptably low level.
-       </para>
-
-       <para>
-        Turning off this option does not affect use of
-        WAL archiving for point-in-time recovery (PITR)
-        (see <xref linkend="backup-online">).
-       </para>
-
-       <para>
-        This option can be set at server start or in the
-        <filename>postgresql.conf</filename> file.  The default is
-        <literal>on</>.
+        This parameter is currently ignored (treated as always <literal>on</>)
+        because turning it off can cause failure to recover from crashes
+        even when no hardware or OS-level error occurred.  This will be
+        fixed in some future release, or else the parameter will be removed
+        entirely.
        </para>
       </listitem>
      </varlistentry>

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f41d39719d0481b5aaf698e0ed9220b44a44e65b..0c14b1f5f1cfbf1ccb53512fadf8f3ba160ed6d5 100644 (file)
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -976,8 +976,7 @@ XLogCheckBuffer(XLogRecData *rdata,
         */
        *lsn = page->pd_lsn;
 
-       if (fullPageWrites &&
-               XLByteLE(page->pd_lsn, RedoRecPtr))
+       if (XLByteLE(page->pd_lsn, RedoRecPtr))
        {
                /*
                 * The page needs to be backed up, so set up *bkpb