Re: B-tree parent pointer and checkpoints

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: B-tree parent pointer and checkpoints
Дата
Msg-id 201110111957.p9BJvv016941@momjian.us
обсуждение исходный текст
Ответ на Re: B-tree parent pointer and checkpoints  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas wrote:
> On 11.03.2011 19:41, Tom Lane wrote:
> > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
> >> On 11.03.2011 17:59, Tom Lane wrote:
> >>> But that will be fixed during WAL replay.
> >
> >> Not under the circumstances that started the original thread:
> >
> >> 1. Backend splits a page
> >> 2. Checkpoint starts
> >> 3. Checkpoint runs to completion
> >> 4. Crash
> >> (5. Backend never got to insert the parent pointer)
> >
> >> WAL replay starts at the checkpoint redo pointer, which is after the
> >> page split record, so WAL replay won't insert the parent pointer. That's
> >> an incredibly tight window to hit in practice, but it's possible in theory.
> >
> > Hmm.  It's not so improbable that checkpoint would start inside that
> > window, but that the parent insertion is still pending by the time the
> > checkpoint finishes is pretty improbable.
> >
> > How about just reducing the deletion-time ERROR for missing downlink to a LOG?
> 
> Well, the code that follows expects to have a valid parent page locked, 
> so you can't literally do just that. But yeah, LOG and aborting the page 
> deletion seems fine to me.

Added to TODO:
Fix problem with btree page splits during checkpoints
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Range Types - typo + NULL string constructor
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Index only scan paving the way for "auto" clustered tables?