From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Failure while inserting parent tuple to B-tree is not fun |
Date: | 2013-10-22 19:24:40 |
Message-ID: | 3673.1382469880@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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.
Note also that the problem might be persistent, eg if you're out of disk
space. In that case, you'd just get the PANIC again at recovery, so now
not only have you crashed all your sessions but you have a database that
won't start up.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-10-22 19:25:43 | Re: Location for external scripts for Extensions? |
Previous Message | Tom Lane | 2013-10-22 19:17:11 | Re: Reasons not to like asprintf |