Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Tue, Jan 25, 2005 at 02:40:51AM -0500, Tom Lane wrote:
>> Offhand I'd say this should draw a "no such cursor as foo" error.
>> I'm too tired to look into why foo still exists after the rollback...
> At this point, gdb says that the portal is in PORTAL_READY state. The
> code says to keep it open and reassign it to the parent subxact. I
> don't remember what the rationale for this was ... I'll review the
> discussion about this.
IIRC, we had agreed that in a sequence like
BEGIN; DECLARE c CURSOR ...; SAVEPOINT x; FETCH FROM c; ROLLBACK TO x; FETCH FROM c; ...
the second fetch should get the second cursor row, ie, the rollback does
not undo the cursor state change caused by the first fetch. This was
frankly driven mostly by implementation considerations, ie, we do not
have any mechanism that would support undoing changes of Executor state.
But I don't think that we really thought about the case of rolling back
the *creation* of a cursor. Neil's example seems to prove that we need
to do that. Even aside from the possibility that the database objects
won't exist any more, the locks taken out during plan startup would get
released by the rollback. So I think the rule ought to be that cursors
created inside a failed subtransaction go away.
I have some recollection that we did that initially and ran into the
problem that the portal holding the ROLLBACK command itself goes away
too soon :-(. So a bit of care will be needed here.
regards, tom lane