Force zero_damaged_pages to be effectively ON during recovery from WAL,

tglsfdc · tglsfdc · commit 0902ece5b925 · 2003-12-01T16:53:19.000Z
since there is no need to worry about damaged pages when we are going to
overwrite them anyway from the WAL.  Per recent discussion.
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.147 2003/11/29 19:51:56 pgsql Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.148 2003/12/01 16:53:19 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -231,7 +231,13 @@ ReadBufferInternal(Relation reln, BlockNumber blockNum,
 		if (status == SM_SUCCESS &&
 			!PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data)))
 		{
-			if (zero_damaged_pages)
+			/*
+			 * During WAL recovery, the first access to any data page should
+			 * overwrite the whole page from the WAL; so a clobbered page
+			 * header is not reason to fail.  Hence, when InRecovery we may
+			 * always act as though zero_damaged_pages is ON.
+			 */
+			if (zero_damaged_pages || InRecovery)
 			{
 				ereport(WARNING,
 						(errcode(ERRCODE_DATA_CORRUPTED),

Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@`
`8`	`8`	`*`
`9`	`9`	`*`
`10`	`10`	`* IDENTIFICATION`
`11`		`- * $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.147 2003/11/29 19:51:56 pgsql Exp $`
	`11`	`+ * $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.148 2003/12/01 16:53:19 tgl Exp $`
`12`	`12`	`*`
`13`	`13`	`*-------------------------------------------------------------------------`
`14`	`14`	`*/`
`@@ -231,7 +231,13 @@ ReadBufferInternal(Relation reln, BlockNumber blockNum,`
`231`	`231`	`if (status == SM_SUCCESS &&`
`232`	`232`	`!PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data)))`
`233`	`233`	`{`
`234`		`- if (zero_damaged_pages)`
	`234`	`+ /*`
	`235`	`+ * During WAL recovery, the first access to any data page should`
	`236`	`+ * overwrite the whole page from the WAL; so a clobbered page`
	`237`	`+ * header is not reason to fail. Hence, when InRecovery we may`
	`238`	`+ * always act as though zero_damaged_pages is ON.`
	`239`	`+ */`
	`240`	`+ if (zero_damaged_pages \|\| InRecovery)`
`235`	`241`	`{`
`236`	`242`	`ereport(WARNING,`
`237`	`243`	`(errcode(ERRCODE_DATA_CORRUPTED),`