Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:


> 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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group