Re: Hot standby, RestoreBkpBlocks and cleanup locks

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Hot standby, RestoreBkpBlocks and cleanup locks
Дата
Msg-id 1232026382.31921.44.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Hot standby, RestoreBkpBlocks and cleanup locks  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Hot standby, RestoreBkpBlocks and cleanup locks  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Hot standby, RestoreBkpBlocks and cleanup locks  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Fri, 2009-01-09 at 19:34 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:

> > It would be useful to nibble away at the patch, committing all the
> > necessary refactorings to make the patch work. That will reduce size of
> > eventual commit.
> 
> Agreed. This in particular is a change I feel pretty confident to commit 
> beforehand.

I'm looking to implement refactoring of this now.

The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.

ISTM easier to do things within the rmgr at the time WAL records are
written, rather than in the rmgr while handling redo.

We currently have 2 bytes spare on the WAL record, so I propose to add
an uint16 xl_info2 field (again). This can then be marked with 2 bits:
* 1 bit to show that it is a cleanup record and may conflict
* 1 bit to show that backup blocks must be applied with cleanup lock
Just to say again that adding these is free: we use no more space
because of alignment.

This avoids another rmgr call and is much more straightforward since we
define how to redo the record at the time it is written, rather than via
a separate mechanism that could mismatch. 

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: cleanup smgr.c of tablespace call
Следующее
От: "Brendan Jurd"
Дата:
Сообщение: Re: fire trigger for a row without update?