Alvaro Herrera wrote:
On Wed, Jan 26, 2005 at 05:10:09PM -0500, Tom Lane wrote:
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.
I don't see a lot of difference between marking the portal FAILED and
destroying it (maybe I'm
Oliver Jowett wrote:
Having the close fail
because of an intervening savepoint rollback isn't great -- the error
will cause an unexpected failure of the current transaction.
Never mind -- I just reread the protocol docs, and it's safe to close a
nonexistant portal. Did this previously issue a
On Fri, Jan 28, 2005 at 12:27:05PM +1300, Oliver Jowett wrote:
Oliver Jowett wrote:
Having the close fail
because of an intervening savepoint rollback isn't great -- the error
will cause an unexpected failure of the current transaction.
Never mind -- I just reread the protocol docs, and
On Wed, Jan 26, 2005 at 03:33:07PM +1100, Neil Conway wrote:
Tom Lane wrote:
The routine's comments need a bit of work too. Otherwise it seems OK.
Neil or anyone else --- see an issue here?
The policy will now be: cursor creation is transaction, but cursor state
modifications (FETCH) are
On Tue, Jan 25, 2005 at 02:06:24PM -0300, Alvaro Herrera wrote:
Hackers,
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
Alvaro Herrera [EMAIL PROTECTED] 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
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2005-01-26 at 12:02 -0300, Alvaro Herrera wrote:
Hmm ... not sure how hard that is.
Would it work to record the sub XID of the deleting subtxn on CLOSE, and
then consider whether to really do the deletion when the subtxn
commits/aborts?
It'd
On Wed, 2005-01-26 at 12:02 -0300, Alvaro Herrera wrote:
and some regression tests for this behavior, but I'm happy to add that
myself if no one beats me to it.
Please do.
Attached is a patch adding regression tests for this change -- I've
already applied it to HEAD.
-Neil
Index:
On Tue, 2005-01-25 at 02:40 -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...
I'm confused; I wasn't involved in the design discussions about portals
and subtransactions this summer, but
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2005-01-25 at 02:40 -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...
I'm confused; I wasn't involved in the design discussions about
On Tue, Jan 25, 2005 at 02:40:51AM -0500, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Someone at Fujitsu pointed out the following bug in 8.0:
begin;
savepoint x;
create table abc (a int);
insert into abc values (5);
declare foo cursor for select * from abc;
rollback to x;
Alvaro Herrera [EMAIL PROTECTED] 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
I wrote:
So I think the rule ought to be that cursors
created inside a failed subtransaction go away.
Other bits of recollection bubbling up: I think that one reason we made
portals not go away instantly on error is that the JDBC guys objected,
feeling that it made for weird special cases at
On Tue, Jan 25, 2005 at 12:32:57PM -0500, Tom Lane wrote:
So the right fix might involve putting the portal into PORTAL_FAILED
state rather than just zapping it completely.
Strangely, the code comes up simpler after the fix. Patch attached.
Regression test pass. Additionaly I tried both
Alvaro Herrera [EMAIL PROTECTED] writes:
! if (portal-status == PORTAL_ACTIVE)
portal-status = PORTAL_FAILED;
! if (portal-status == PORTAL_ACTIVE || portal-status ==
PORTAL_READY)
portal-status = PORTAL_FAILED;
I don't
Tom Lane wrote:
The routine's comments need a bit of work too. Otherwise it seems OK.
Neil or anyone else --- see an issue here?
The policy will now be: cursor creation is transaction, but cursor state
modifications (FETCH) are non-transactional -- right? I wonder if it
wouldn't be more
Neil Conway [EMAIL PROTECTED] writes:
Someone at Fujitsu pointed out the following bug in 8.0:
begin;
savepoint x;
create table abc (a int);
insert into abc values (5);
declare foo cursor for select * from abc;
rollback to x;
fetch from foo; -- hits an Assert()
Offhand I'd say this should
17 matches
Mail list logo
