Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Date
Msg-id 201209152100.13244.andres@2ndquadrant.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Saturday, September 15, 2012 06:29:25 PM Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Definitions aside, I think it's a pretty scary issue. It basically means
> > that if you have a recovery (crash or archive) during which you read a
> > buffer into memory, the buffer won't be checkpointed.  So if, before the
> > buffer is next evicted, you have a crash, and if at least one checkpoint
> > has intervened between the most recent WAL-logged operation on the
> > buffer and the crash, you're hosed.  That's not a terribly unlikely
> > scenario.
> 
> This is only an issue on standby slaves or when doing a PITR recovery, no?
> As far as I can tell from the discussion, it would not affect crash
> recovery, because we don't do restartpoints during crash recovery.
I think unfortunately it does. At the end of recovery we perform a 
END_OF_RECOVERY checkpoint that seems to suffer from these issues. While 
CreateCheckPoint() itself treats that kind of checkpoint similarly to a 
shutdown checkpoint it doesn't pass that similarity to BufferSync (via 
CheckPointGuts->CheckPointBuffers).

I hope I missed something ...

Greetings,

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: Peter Eisentraut
Date:
Subject: _FORTIFY_SOURCE by default?