Re: Disaster! - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Disaster!
Date
Msg-id 8707.1074907284@sss.pgh.pa.us
Whole thread Raw
In response to Re: Disaster!  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Disaster!  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Tom's answer will be undoubtly better ...

Nope, I think you got all the relevant points.

The only thing I'd add after having had more time to think about it is
that this seems very much like the problem we noticed recently with
recovery-from-WAL being broken by the new code in bufmgr.c that tries to
validate the header fields of any page it reads in.  We had to add an
escape hatch to disable that check while InRecovery, and I expect what
we will end up with here is a few lines added to slru.c to make it treat
read-past-EOF as a non-error condition when InRecovery.  Now the clog
code has always had all that paranoid error checking, but because it
deals in such tiny volumes of data (only 2 bits per transaction), it's
unlikely to suffer an out-of-disk-space condition.  That's why we hadn't
seen this failure mode before.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Recursive optimization of IN subqueries
Next
From: Josh Berkus
Date:
Subject: Re: [pgsql-advocacy] PostgreSQL installation CD based on Morphix