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
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 |