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.

doc/src/sgml/config.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.36.2.2 2006/02/12 19:19:37 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.36.2.3 2006/03/28 22:01:24 tgl Exp $
 -->
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -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
+        This parameter is currently ignored (treated as always <literal>on</>)
-        might lead to a corrupt database after an operating system crash
+        because turning it off can cause failure to recover from crashes
-        or power failure. The risks are similar to turning off
+        even when no hardware or OS-level error occurred.  This will be
-        <varname>fsync</>, though smaller.  It may be safe to turn off
+        fixed in some future release, or else the parameter will be removed
-        this option if you have hardware (such as a battery-backed disk
+        entirely.
-        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</>.
        </para>
       </listitem>
      </varlistentry>

src/backend/access/transam/xlog.c

@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.222.2.2 2006/01/05 00:54:50 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.222.2.3 2006/03/28 22:01:25 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -976,8 +976,7 @@ XLogCheckBuffer(XLogRecData *rdata,
 	 */
 	*lsn = page->pd_lsn;
 
-	if (fullPageWrites &&
+	if (XLByteLE(page->pd_lsn, RedoRecPtr))
-		XLByteLE(page->pd_lsn, RedoRecPtr))
 	{
 		/*
 		 * The page needs to be backed up, so set up *bkpb