Re: How to crash postgres using savepoints - Mailing list pgsql-bugs

From Tom Lane
Subject Re: How to crash postgres using savepoints
Date
Msg-id 1026.1163711282@sss.pgh.pa.us
Whole thread Raw
In response to Re: How to crash postgres using savepoints  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> ... Did we explicitly decide
>> to do this differently from spec, and if so why?

> Yeah, we did.  I think the rationale was what happens when you have
> another savepoint in the middle, say

> SAVEPOINT foo;
> SAVEPOINT bar;
> SAVEPOINT foo;

Ah, right.  I'm not in a huge hurry to change this, anyway ... it's not
like there aren't any number of other ways to run the system out of
locktable slots.

(I spent a bit of time thinking about whether we needed locktable
entries for subxacts at all, but I don't see how to preserve the
stop-waiting-on-subxact-abort behavior of XactLockTableWait without
them.  We can't just wait on the subxact's topmost parent.)

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: How to crash postgres using savepoints
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] BUG #2737: hash indexing large table fails,while btree of same index works