Re: Nested transactions and tuple header info

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, David Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested transactions and tuple header info
Date: 2004-06-02 14:47:04
Message-ID: 200406021447.i52El4i10948@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > On Wed, Jun 02, 2004 at 09:52:28AM -0400, Tom Lane wrote:
> >> AFAICS your proposal does not support this. The two cursors' snapshots
> >> will differ only in the recorded current-cid for the outer transaction.
> >> If the subtrans has overwritten xmin/cmin, there is no way to make that
> >> decision correctly.
>
> > Why would it overwrite cmin? Only a new xmin is needed (and cmax and
> > xmax, but the cursors don't care about those)
>
> If you overwrite xmin and not cmin, you've created a nonsensical
> situation. How do you distinguish this tuple from tuples created by the
> subxact itself? More generally, cmin is only meaningful in combination
> with a particular transaction ID; you can't just arbitrarily replace
> xmin without changing cmin.
>
> I've been trying to think of ways to solve these problems by having a
> main xact and all its subxacts share a common CID sequence (ie, a
> subxact would have its own xid but would not start CID over at one).
> If you assume that, then Bruce's idea may indeed work, since you would
> never replace xmin in a way that would shift the interpretation of cmin
> into a different CID sequence. But I suspect there is a simpler way to
> solve it given that constraint.

I thought about using a global command counter. The problem there is
that there is no way to control the visibility of tuples by other
transactions on commit except going back end fixing up tuples, which is
unacceptable.

By creating phantoms, we can decide if an specific xmin/xmax pair should
be appear as committed and set it accordingly on commit.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-06-02 14:48:29 Re: Converting postgresql.conf parameters to kilobytes
Previous Message Tom Lane 2004-06-02 14:46:02 Re: Converting postgresql.conf parameters to kilobytes