Re: [PATCHES] nested xacts and phantom Xids

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] nested xacts and phantom Xids
Date: 2004-06-30 00:19:15
Message-ID: 20040630001915.GC26189@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Tue, Jun 29, 2004 at 06:59:20PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > As with the bufmgr.c original patch, I don't really know how to test
> > that this actually works. [...]
>
> I forgot to mention to you that that code didn't work at all, btw.

Bad news, I guess.

> The other theory we could adopt is that cursors stay open till main xact
> commit; this would imply not releasing buffer refcounts at subxact
> commit, plus any other resources needed by the cursor. We're already
> holding locks that way and it probably wouldn't be a big change to make
> bufmgr work the same. I'm not sure that there are any other resources
> involved, other than the Portal memory which we already handle properly.

Well, AFAIR originally I had thought that refcounts should be held at
subtrans commit; you suggested that there was no reason for a subtrans
to keep a buffer refcount and that was it. I think the open cursor is a
good reason why the count should be kept; it appears less useful if you
can't use the cursor anywhere out of the level that created it.

> Oh, there's another point: what happens if an outer xact level declares
> a cursor, which is then FETCHed from by a subtransaction? At minimum we
> have the problem that this could change the set of buffer pins held,
> which breaks the present bufmgr solution entirely. It gets even more
> interesting if you are of the opinion that subtransaction failure should
> cause the effects of the FETCH to be undone --- we have no way to do
> that at all, because there's no mechanism for saving/restoring the state
> of an entire execution plan tree.

Hmm ... yes, this could be very ugly indeed, but I haven't even looked
at the executor code so I can't comment. Are executor nodes copyable?

Oh, and I've been playing with large objects and I've encountered bugs
elsewhere. I'll look at it with the new patch you just posted.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2004-06-30 00:27:07 Re: Accessing Specific Schemas
Previous Message Tom Lane 2004-06-29 23:37:13 Re: nested xacts and phantom Xids

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2004-06-30 01:46:57 Re: PITR Archive Recovery
Previous Message Tom Lane 2004-06-29 23:37:13 Re: nested xacts and phantom Xids