Thread: Re: Nested transactions and tuple header info

Re: Nested transactions and tuple header info

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> 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.

No, I said own xid --- so the "phantom xid" part is still there.  But
your idea definitely does *not* work unless you use a single CID
sequence for the whole main xact; and I'm still wondering if there's
not a simpler implementation possible given that assumption.
        regards, tom lane


Re: Nested transactions and tuple header info

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> 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.
> 
> No, I said own xid --- so the "phantom xid" part is still there.  But
> your idea definitely does *not* work unless you use a single CID
> sequence for the whole main xact; and I'm still wondering if there's
> not a simpler implementation possible given that assumption.

I don't understand why a single counter is needed for phantom xids.  We
keep the cmin/cmax on the tuple already, and our own backend can look up
the xmin/xmax that goes with the phantom.

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


Re: Nested transactions and tuple header info

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't understand why a single counter is needed for phantom xids.  We
> keep the cmin/cmax on the tuple already, and our own backend can look up
> the xmin/xmax that goes with the phantom.

Oh, so you're thinking of an internal table that provides a mapping back
to the replaced xmin?  Ugh.  Perhaps it could be made to work, but it's
a lot of mechanism, and it will slow down visibility checks (since
AFAICS you'd have to check every subxid against the phantoms table).
If we go with a global CID counter then we don't have to add that step.

A global CID counter would also simplify other visibility tests.  Alvaro
hasn't said anything about how he's doing visibility checks across
different subxacts of the same main xact, but without global CID there
would need to be some pretty ugly checks to determine whether a subxact
happened before or after the CID cutoff your outer xact is interested
in.
        regards, tom lane


Re: Nested transactions and tuple header info

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't understand why a single counter is needed for phantom xids.  We
> > keep the cmin/cmax on the tuple already, and our own backend can look up
> > the xmin/xmax that goes with the phantom.
> 
> Oh, so you're thinking of an internal table that provides a mapping back
> to the replaced xmin?  Ugh.  Perhaps it could be made to work, but it's
> a lot of mechanism, and it will slow down visibility checks (since
> AFAICS you'd have to check every subxid against the phantoms table).

My idea was to have a tuple bit indicating the xid is a phantom.

> If we go with a global CID counter then we don't have to add that step.

Seems Alvaro is already using a global counter.

> A global CID counter would also simplify other visibility tests.  Alvaro
> hasn't said anything about how he's doing visibility checks across
> different subxacts of the same main xact, but without global CID there
> would need to be some pretty ugly checks to determine whether a subxact
> happened before or after the CID cutoff your outer xact is interested
> in.

If a global counter will reduce the number of phantom checks, then good.
However, I assume Alvaro has to access the creation/expire xid to
determine if the subtransaction committed, so I didn't think a global
counter would help reduce the number of lookups.

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


Re: Nested transactions and tuple header info

From
Alvaro Herrera
Date:
On Wed, Jun 02, 2004 at 11:12:31AM -0400, Tom Lane wrote:

> A global CID counter would also simplify other visibility tests.  Alvaro
> hasn't said anything about how he's doing visibility checks across
> different subxacts of the same main xact, but without global CID there
> would need to be some pretty ugly checks to determine whether a subxact
> happened before or after the CID cutoff your outer xact is interested
> in.

Yes, I'm using a global CID counter.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La vida es para el que se aventura"



Re: Nested transactions and tuple header info

From
Alvaro Herrera
Date:
On Wed, Jun 02, 2004 at 12:23:37PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:

> > If we go with a global CID counter then we don't have to add that step.
> 
> Seems Alvaro is already using a global counter.

I think I stated already that I'm in fact using it.  Not sure why it
didn't show up in the list.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"¿Que diferencia tiene para los muertos, los huérfanos, y aquellos que han
perdido su hogar, si la loca destrucción ha sido realizada bajo el nombre
del totalitarismo o del santo nombre de la libertad y la democracia?" (Gandhi)



Re: Nested transactions and tuple header info

From
Bruce Momjian
Date:
Alvaro Herrera wrote:
> On Wed, Jun 02, 2004 at 12:23:37PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> 
> > > If we go with a global CID counter then we don't have to add that step.
> > 
> > Seems Alvaro is already using a global counter.
> 
> I think I stated already that I'm in fact using it.  Not sure why it
> didn't show up in the list.

Yes, I saw it.  I wrote "seems" when I should have wrote it as a fact.

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


Re: Nested transactions and tuple header info

From
Alvaro Herrera
Date:
On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
>
> > No, I said own xid --- so the "phantom xid" part is still there.  But
> > your idea definitely does *not* work unless you use a single CID
> > sequence for the whole main xact; and I'm still wondering if there's
> > not a simpler implementation possible given that assumption.
> 
> I don't understand why a single counter is needed for phantom xids.  We
> keep the cmin/cmax on the tuple already, and our own backend can look up
> the xmin/xmax that goes with the phantom.

Not sure either way (maybe you are right), but I use the global counter
anyway because some tests would become a very ugly mess if I didn't.  I
think the phantom idea is also simpler with the global counter.

And I see no reason to use local counter.  We certainly are not
hitting the limit with the global counter, as Tom pointed out recently
in a thread about the aborted CID bitmaps.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Crear es tan difícil como ser libre" (Elsa Triolet)



Re: Nested transactions and tuple header info

From
Bruce Momjian
Date:
Alvaro Herrera wrote:
> On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> > > No, I said own xid --- so the "phantom xid" part is still there.  But
> > > your idea definitely does *not* work unless you use a single CID
> > > sequence for the whole main xact; and I'm still wondering if there's
> > > not a simpler implementation possible given that assumption.
> > 
> > I don't understand why a single counter is needed for phantom xids.  We
> > keep the cmin/cmax on the tuple already, and our own backend can look up
> > the xmin/xmax that goes with the phantom.
> 
> Not sure either way (maybe you are right), but I use the global counter
> anyway because some tests would become a very ugly mess if I didn't.  I
> think the phantom idea is also simpler with the global counter.
> 
> And I see no reason to use local counter.  We certainly are not
> hitting the limit with the global counter, as Tom pointed out recently
> in a thread about the aborted CID bitmaps.

Sure, use the global counter if it helps.  My only point was that I
didn't see how a global counter could reduce the number of times we have
to look up the phantom xid to find the xmin/xmax.

However, if you have a map showing which command counter goes with which
subtransaction, then you _certainly_ could reduce the number of phantom
lookups.  (The command counter cmin/cmax tells you the xmin/xmax).  In
fact, in that case, the phatom xid's are only used on commit so you can
make certain tuples visible/invisible to other transactions.

To find the phantom xid idea, I had to wander around the house for a few
hours thinking of what was in that tuple header and how this could be
accomplished.  I am sorry I led Alvaro initially into thinking he didn't
need to keep the cmin.

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