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

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Date
Msg-id 99C1FCEF-43B0-417F-832A-CDC8938B7A14@gmail.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>)
Responses Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sep 15, 2012, at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> 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
thebuffer 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.

No, I think it does affect crash recovery. Whether or not restartspoints happen during recovery doesn't matter; what
doesmatter is that after recovery there may be shared buffers that are erroneously not marked as permanent. Such
bufferswon't be checkpointed except at shutdown time, which is wrong. 

...Robert




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: _FORTIFY_SOURCE by default?
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.