Robert Haas <robertmh...@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 the buffer 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.
> While I can't claim to understand exactly what our standards for forcing an
> immediate minor release are, I think this is pretty darn bad. I certainly
> don't want my customers running with this for a minute longer than necessary,
> and I feel really bad for letting it get into a release, let alone go
> undetected for this long. :-(
There's been some discussion about it among -core already. The earliest
we could possibly do anything would be a release this coming week (that
is, wrap Thursday for release Monday 9/24). However, considering that
a lot of key people will be attending PG Open between now and Thursday,
I'm not sure how practical that really would be. Waiting a week might
be better, and it would give more time for initial bug reports against
9.2.0 to filter in.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
