Re: bug w/ cursors and savepoints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bug w/ cursors and savepoints
Date
Msg-id 20637.1106777409@sss.pgh.pa.us
Whole thread Raw
In response to Re: bug w/ cursors and savepoints  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: bug w/ cursors and savepoints  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Deferrable Unique Constraints
Next
From: Alvaro Herrera
Date:
Subject: Re: bug w/ cursors and savepoints