On Saturday, September 15, 2012 06:29:25 PM Tom Lane wrote: > 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. I think unfortunately it does. At the end of recovery we perform a END_OF_RECOVERY checkpoint that seems to suffer from these issues. While CreateCheckPoint() itself treats that kind of checkpoint similarly to a shutdown checkpoint it doesn't pass that similarity to BufferSync (via CheckPointGuts->CheckPointBuffers).
I hope I missed something ... Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
