Horton

Re: B-tree parent pointer and checkpoints

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
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-11T16:44:33Z
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 17:59, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> On 10.03.2011 22:50, Bruce Momjian wrote:
>>> Bruce Momjian wrote:
>>
>> Has this been addressed?
>>>
>>> I see we have with this commit:
>>>
>>> 9de3aa65f01fb51cbc725e8508ea233e4e92c46c
>
>> We fixed GiST. B-tree still has the issue that if you have a checkpoint
>> in the middle of an insert, and crash, you might be left with a leaf
>> node without a downlink in the parent.
>
> 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.

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