On Mon, Sep 17, 2012 at 11:14 AM, Andres Freund <and...@2ndquadrant.com> wrote: > I just noted during investigating of the impact of the fakerelcache bug that > contrary to whats claimed at several places END_OF_RECOVERY checkpoints do > *not* behave the same way CHECKPOINT_IS_SHUTDOWN ones do. Which doesn't seem > to > be a good idea. E.g. the impact of this bug would have been smaller if they > were really treated the same. Unless I missed something thats the only place > of > relevance that treats them differently. > Imo treating them different in some remote places (2 calls away) is a good way > to introduce further bugs.
OK, I can agree with that. As a backstop against future mistakes, it makes some sense to me. >> Maybe what we should do is - if this is an end-of-recovery checkpoint >> - *assert* that the BM_PERMANENT bit is set on every buffer we find. >> That would provide a useful cross-check that we don't have a bug >> similar to the one Jeff already fixed in any other code path. > I haven't looked into the details, but can't a new unlogged relation be > created > since the last checkpoint and thus have pages in s_b? Data changes to unlogged relations are not WAL-logged, so there's no reason for recovery to ever read them. Even if such a reason existed, there wouldn't be anything to read, because the backing files are unlinked before WAL replay begins. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
