Re: bug w/ cursors and savepoints

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug w/ cursors and savepoints
Date: 2005-01-25 08:13:45
Message-ID: 1106640825.9525.18.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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, but my understanding is that making
portals non-transactional was the conclusion. Shouldn't that imply that
a DECLARE in an aborted subtransaction should persist? Certainly, it
seems AtSubAbort_Portals() makes sure that READY portals created in an
aborted subtxn are adopted by the parent transaction.

(It might make sense to persist the cursor to the parent transaction,
unless the aborted transaction created a database object the cursor
depends upon, a la [1] -- but in that case, IMHO we ought to give a
different error message than "no such cursor".)

If someone can shed some light on what the spec for this behavior ought
to be, I'd be happy to fix the bug.

-Neil

[1] http://archives.postgresql.org/pgsql-hackers/2004-07/msg00349.php

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-01-25 08:20:02 Re: bug w/ cursors and savepoints
Previous Message Tom Lane 2005-01-25 07:45:22 Re: Built-in casts for ltree