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.
|
Список | 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 по дате отправления: