Re: bug w/ cursors and savepoints

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-27 23:12:31
Message-ID: 41F9755F.8080006@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 looking at the wrong code). So I just took the
> simpler approach; patch attached.

I assume that you can CLOSE a failed portal, but you can't CLOSE a
destroyed portal (because it's not there any more)?

This is important for the JDBC driver as it creates portals internally,
does fetches as the application code demands, then closes the portal at
some point after the application is done with it. Having the close fail
because of an intervening savepoint rollback isn't great -- the error
will cause an unexpected failure of the current transaction. This can
happen even if the application doesn't try to use the portal (via
ResultSet) after the savepoint rollback at all.

It wouldn't be so bad if the driver could track savepoint boundaries,
but the current protocol doesn't make that easy..

-O

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-01-27 23:22:18 Re: Strange issue with initdb on 8.0 and Solaris automounts
Previous Message Simon Riggs 2005-01-27 22:55:33 Re: Permissions on aggregate component functions