Re: B-tree parent pointer and checkpoints

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Greg Stark <gsstark@mit.edu>, Teodor Sigaev <teodor@sigaev.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Oleg Bartunov <oleg@sai.msu.su>
Date: 2011-03-11T17:49:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Rewrite the GiST insertion logic so that we don't need the post-recovery

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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com