Re: Assertion failure in cvs head.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Subject: Re: Assertion failure in cvs head.
Date: 2004-09-16 21:16:33
Message-ID: 12467.1095369393@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kris Jurka <books(at)ejurka(dot)com> writes:
> I'm implementing savepoint support for the JDBC driver and I'm seeing an
> assertion failure in cvs head this morning. It seems related to using
> both savepoints and the v3 protocol.

After some study I've decided that that Assert is simply erroneous;
removing it is the easiest fix.

The reason the problem doesn't show up in psql is that the simple-Query
path in postgres.c always drops the Portal before doing finish_xact_command.
Extended query mode doesn't do that, and so we had a situation where an
already-aborted transaction owned a Portal that wasn't aborted (since it
hadn't existed when AtSubAbort_Portals() ran). PortalDrop is perfectly
capable of handling this, at least for a portal containing a ROLLBACK
command (which isn't going to own any resources of significance); so the
right answer is just to soldier on.

It occurs to me that the protocol documentation is a bit out of date in
this connection, since it says "a named portal object lasts till the end
of the current transaction", whereas it needs to say something more like
"till the end of the current transaction or subtransaction". Since we
are trying to pretend that there are no subtransactions, only
SAVEPOINTs, I'm not sure how to word it. Comments?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Conal Tuohy 2004-09-17 02:14:31 Error starting service on Win2k
Previous Message PostgreSQL Bugs List 2004-09-16 20:14:41 BUG #1255: cannot connect remotely