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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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]>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)

In response to


pgsql-hackers by date

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

pgsql-patches by date

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

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