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)
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 |
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 |