Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c
Дата
Msg-id 201209200107.51533.andres@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "David Johnston"
Дата:
Сообщение: Re: Invalid optimization of VOLATILE function in WHERE clause?
Следующее
От: Florian.Schoppmann@emc.com (Florian Schoppmann)
Дата:
Сообщение: Re: Invalid optimization of VOLATILE function in WHERE clause?