Re: bug w/ cursors and savepoints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug w/ cursors and savepoints
Date: 2005-01-26 22:10:09
Message-ID: 20637.1106777409@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Our conclusion at the time was that cursors created inside failed
> subtransactions should remain open. See the proposal and followup
> discussion starting here:

> http://archives.postgresql.org/pgsql-hackers/2004-07/msg00700.php

> If we want to keep this behavior then we should not close all READY
> cursors as per my previous patch. We should keep them open, and only
> mark FAILED those cursors that are related to state reversed by the
> aborting subtransaction.

> I don't see any way to do this cleanly, until we have some relcache-
> dependency checking on Portals (maybe anything else?). Not sure what we
> can do about it right now, with 8.0.1 release tomorrow.

I don't think we have a lot of choices: we have to destroy (or at least
mark FAILED) all such cursors for the time being. The whole question of
cursor transaction semantics could stand to be revisited in 8.1, but we
can't ship the system with such a trivial crashing bug.

Note that dependency tracking would not in itself be enough to solve the
problem, since the question is not merely what objects the cursor
depends on, but whether their definitions were changed in the failed
subtransaction. Talk about messy :-(

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-01-26 22:49:09 Re: bug w/ cursors and savepoints
Previous Message Greg Stark 2005-01-26 20:48:05 Re: Deferrable Unique Constraints