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 →
-
Rewrite the GiST insertion logic so that we don't need the post-recovery
- 9de3aa65f01f 9.1.0 cited
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