Skip site navigation (1) Skip section navigation (2)

Re: nested-xacts cursors (was Re: Performance with new nested-xacts code)

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: nested-xacts cursors (was Re: Performance with new nested-xacts code)
Date: 2004-07-03 05:45:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:

  declare cursor c ...;
  fetch 1 from c;		-- returns tuple 1
    fetch 1 from c;		-- returns tuple 2
  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]>)
"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)

In response to


pgsql-hackers by date

Next:From: Andreas PflugDate: 2004-07-03 07:25:21
Subject: Re: Schedule, feature freeze, etc
Previous:From: Alvaro HerreraDate: 2004-07-03 03:13:51
Subject: Re: PREPARE and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group