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 doc
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 wa
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
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: sr
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?
On Wed, 2005-01-26 at 12:02 -0300, Alvaro Herrera wrote:
> > 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 consistent to make cursor deletion (CLOSE)
> > transactional as well
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> 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
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 looking at the wro
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
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
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 (FETC
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 consiste
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;
On Tue, Jan 25, 2005 at 03:14:07PM -0300, Alvaro Herrera wrote:
> 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 t
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 cas
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 t
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 PORTA
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;
>
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 abo
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, bu
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 th
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()
commit;
The stacktrace is:
#2 0x0826367b in ExceptionalCondition (condi
22 matches
Mail list logo
