Horton

Re: B-tree parent pointer and checkpoints

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.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-09-06T13:49:39Z
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 Tue, Sep 6, 2011 at 9:45 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> Do you really need to hold the page locks for all that time, or could
>> you cheat?  Like... release the locks on the split pages but then go
>> back and reacquire them to clear the flag...
>
> Hmm, there's two issues with that:
>
> 1. While you're not holding the locks on the child pages, someone can step
> onto the page and see that the MISSING_DOWNLINK flag is set, and try to
> finish the split for you.
>
> 2. If you don't hold the page locked while you clear the flag, someone can
> start and finish a checkpoint after you've inserted the downlink, and before
> you've cleared the flag. You end up in a scenario where the flag is set, but
> the page in fact *does* have a downlink in the parent.

It seems like both of these could be handled by making the code that
repairs the damage insert the downlink into the parent only if it's
not already present.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company