From fdc28fdcfa68c2a732ebcc2e35e797fab46cfa14 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 28 Mar 2006 22:01:25 +0000 Subject: [PATCH] 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 | 38 +++++-------------------------- src/backend/access/transam/xlog.c | 5 ++-- 2 files changed, 8 insertions(+), 35 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 1e76b3a55a6..37dbaddf7c5 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1,5 +1,5 @@ Server Configuration @@ -1354,40 +1354,14 @@ SET ENABLE_SEQSCAN TO OFF; When this option is on, the 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.) - 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 - 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. - - - - Turning off this option does not affect use of - WAL archiving for point-in-time recovery (PITR) - (see ). - - - - This option can be set at server start or in the - postgresql.conf file. The default is - on. + This parameter is currently ignored (treated as always 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. diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 0e14d9db99b..c20025f38bf 100644 --- a/src/backend/access/transam/xlog.c +++ b/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 && - XLByteLE(page->pd_lsn, RedoRecPtr)) + if (XLByteLE(page->pd_lsn, RedoRecPtr)) { /* * The page needs to be backed up, so set up *bkpb