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 D3B1605C-6B5D-4F19-BE3C-4398762E4412@gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: git tree
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.