Horton

Re: B-tree parent pointer and checkpoints

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, 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-06T14:42:03Z
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 10:03 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> 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.
>
> I am sorry to be dumping all these new open issues so late in the 9.1
> cycle --- I only now got time to go back over my emails.  Many are from
> March and later.

Well, I don't think we're likely to do anything about this for 9.1.
For 9.2, possibly, we can improve it.

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