Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Дата
Msg-id 99C1FCEF-43B0-417F-832A-CDC8938B7A14@gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: _FORTIFY_SOURCE by default?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.