Horton

Re: B-tree parent pointer and checkpoints

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
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:41:09Z
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

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?

			regards, tom lane