From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c |
Date: | 2012-09-19 23:07:51 |
Message-ID: | 201209200107.51533.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers 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
From | Date | Subject | |
---|---|---|---|
Next Message | User Sakamotomsh | 2012-09-20 03:48:54 | reorg - pg_reorg: Fixes to work with 9.3dev. |
Previous Message | Tom Lane | 2012-09-19 21:59:08 | pgsql: Stamp 8.3.21. |
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Schoppmann | 2012-09-20 01:26:10 | Re: Invalid optimization of VOLATILE function in WHERE clause? |
Previous Message | David Johnston | 2012-09-19 21:59:28 | Re: Invalid optimization of VOLATILE function in WHERE clause? |