Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c
Date
Msg-id 201209200107.51533.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tuesday, September 18, 2012 04:18:01 AM Robert Haas wrote:
> >> 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.
Back then I thought that resetting the relation by copying the init fork might 
use the buffer cache. It doesn't atm...

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: "David Johnston"
Date:
Subject: Re: Invalid optimization of VOLATILE function in WHERE clause?
Next
From: Florian.Schoppmann@emc.com (Florian Schoppmann)
Date:
Subject: Re: Invalid optimization of VOLATILE function in WHERE clause?