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 D3B1605C-6B5D-4F19-BE3C-4398762E4412@gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sep 14, 2012, at 12:17 PM, Simon Riggs <simon@2ndQuadrant.com> wrote:
> The bug itself is not major, but the extent and user impact is serious.

I don't think I understand how you're using the word major there.  I seem to recall some previous disputation between
youand I about the use of that term, so maybe it would be good to get that cleared up.  To me major and serious mean
aboutthe same thing, so it can't for me be one but not the other. 

Definitions aside, I think it's a pretty scary issue. It basically means that if you have a recovery (crash or archive)
duringwhich you read a buffer into memory, the buffer won't be checkpointed.  So if, before the buffer is next evicted,
youhave a crash, and if at least one checkpoint has intervened between the most recent WAL-logged operation on the
bufferand the crash, you're hosed.  That's not a terribly unlikely scenario. 

While I can't claim to understand exactly what our standards for forcing an immediate minor release are, I think this
ispretty darn bad. I certainly don't want my customers running with this for a minute longer than necessary, and I feel
reallybad for letting it get into a release, let alone go undetected for this long. :-( 

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: git tree
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.