From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | cannot drop active portal |
Date: | 2004-04-22 02:06:50 |
Message-ID: | 20040422020650.GA4660@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hackers,
While playing with code to enable subtransactions in the storage
manager, I run across this strangeness:
alvherre=# begin; begin; -- start a subtransaction
BEGIN
BEGIN
alvherre=# drop table foo; -- no such table
ERROR: no existe la tabla "foo"
alvherre=# commit;
ERROR: cannot drop active portal
alvherre=#
This happens while PortalDrop() tries to drop an active portal. In this
state, I can't do anything else short of closing the connection. But
this doesn't happen if I try to run a non-utility bogus statement
("SELECT foo"); the system then allows me to rollback the transaction.
Why is a portal kept active after a utility statement fails? I've been
reading tcop/postgres.c but I can't find what's different between
utility and non-utility.
Any clues?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"People get annoyed when you try to debug them." (Larry Wall)
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-04-22 02:21:13 | Re: contrib vs. gborg/pgfoundry for replication solutions |
Previous Message | Joe Conway | 2004-04-22 01:58:07 | Re: contrib vs. gborg/pgfoundry for replication solutions |