Re: How to crash postgres using savepoints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Joseph Shraibman <jks(at)selectacast(dot)net>, pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: How to crash postgres using savepoints
Date: 2006-11-16 21:08:02
Message-ID: 1026.1163711282@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2006-11-16 22:48:16 Re: [PERFORM] BUG #2737: hash indexing large table fails, while btree of same index works
Previous Message Alvaro Herrera 2006-11-16 20:59:33 Re: How to crash postgres using savepoints

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Davis 2006-11-16 23:17:13 Re: PostgreSQL: Question about rules
Previous Message Gurjeet Singh 2006-11-16 21:07:35 Re: [HACKERS] Not your father's question about deadlocks