Automatically force zero_damaged_pages while InRecovery?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Automatically force zero_damaged_pages while InRecovery?
Date: 2003-11-29 18:37:32
Message-ID: 8212.1070131052@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

We have seen a couple instances recently of WAL recovery failing due to
the recently added code that validates a page header as soon as the page
is read in, for example Olivier Prenant's crash report here:

http://archives.postgresql.org/pgsql-hackers/2003-10/msg01505.php

This failure is actually entirely pointless, because (AFAIK) any page
that is brought in during WAL recovery is going to be overwritten in
toto from the WAL log. So it would be safe to run WAL recovery with
zero_damaged_pages enabled. Rather than expecting DBAs to think of that
under the stress of a crashed-database situation, I propose that we do
it for them:

*** src/backend/storage/buffer/bufmgr.c.orig Fri Nov 21 12:41:31 2003
--- src/backend/storage/buffer/bufmgr.c Sat Nov 29 13:35:14 2003
***************
*** 231,237 ****
if (status == SM_SUCCESS &&
!PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data)))
{
! if (zero_damaged_pages)
{
ereport(WARNING,
(errcode(ERRCODE_DATA_CORRUPTED),
--- 231,237 ----
if (status == SM_SUCCESS &&
!PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data)))
{
! if (zero_damaged_pages || InRecovery)
{
ereport(WARNING,
(errcode(ERRCODE_DATA_CORRUPTED),

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2003-11-29 19:31:03 Re: Automatically force zero_damaged_pages while InRecovery?
Previous Message Bruce Momjian 2003-11-29 18:26:48 Re: -fpic vs. -fPIC