Re: Failure while inserting parent tuple to B-tree is not fun
От | Andres Freund |
---|---|
Тема | Re: Failure while inserting parent tuple to B-tree is not fun |
Дата | |
Msg-id | 20131022202603.GA9370@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Failure while inserting parent tuple to B-tree is not fun (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Failure while inserting parent tuple to B-tree is not fun
|
Список | 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 по дате отправления: