On Thu, Jul 01, 2004 at 10:19:08AM -0400, Tom Lane wrote:
> AFAICS we can't allow an inner transaction to use a cursor that was
> declared in an outer transaction, because if the inner transaction fails
> then it's not just a matter of the FETCH not rolling back; the
> subtransaction abort will restore state in the bufmgr and other places
> that is simply inconsistent with the state of the cursor's plantree.
Well! I was reading some code about cursors/portals and it certainly is
not an easy issue to handle.
> begin;
> begin;
> declare cursor c ...;
> end; -- cursor, bufmgr state NOT changed here
> fetch from c;
I tried modifying bufmgr, relcache and catcache to see this (with a
simple example) and it works.
> It seems though that we might have a lot of problems with figuring out
> which subsystems ought to restore state at subxact commit and which not.
AFAICS the only ones that restore state at subxact commit right now are
relcache, catcache and bufmgr. I think the three of them should not do
so to support this.
> [...] so the rule would have to be something like "cursors can only be
> touched by the highest subxact nesting level they have ever been
> visible to". Yuck.
Yeah. Another answer would be to reset the executor state if the cursor
is modified in a subtransaction that aborts:
begin;
declare cursor c ...;
fetch 1 from c; -- returns tuple 1
begin;
fetch 1 from c; -- returns tuple 2
rollback;
fetch 1 from c; -- returns tuple 1 again
This is mightly ugly but I think it's the most usable of the options
seen so far. I'm not sure how hard is to do that -- maybe it's just a
matter of running PortalStart() again for the cursor?
What do you think?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
