Re: Failure while inserting parent tuple to B-tree is not fun - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Failure while inserting parent tuple to B-tree is not fun
Date
Msg-id 20131022202603.GA9370@awork2.anarazel.de
Whole thread Raw
In response to Re: Failure while inserting parent tuple to B-tree is not fun  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Failure while inserting parent tuple to B-tree is not fun  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2013-10-22 15:24:40 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-10-22 21:29:13 +0300, Heikki Linnakangas wrote:
> >> We could put a critical section around the whole recursion that inserts the
> >> downlinks, so that you would get a PANIC and the incomplete split mechanism
> >> would fix it at recovery. But that would hardly be an improvement.
> 
> > For me this clearly *has* to be in a critical section with the current
> > code. I had always assumed all multi-part actions would be.
> 
> No, that's hardly a good idea.  As Heikki says, that would amount to
> converting an entirely foreseeable situation into a PANIC.

But IIUC this can currently lead to an index giving wrong answers, not
"just" fail at further inserts? I think if we half-split (without
inserting the downlink) a page several times, via different child-pages,
we might "suceed" in splitting but we'll have corrupted left/right
links. With complete splits such things should be prevented by the
page-level locks we hold, but that's not the case anymore.
If so that could, especially in combination with unique indexes, lead to
quite nasty data corruption

> I wonder whether Heikki's approach could be used to remove the need for
> the incomplete-split-fixup code altogether, thus eliminating a class of
> recovery failure possibilities.

That'd be better...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Reasons not to like asprintf
Next
From: Tom Lane
Date:
Subject: Re: Reasons not to like asprintf