Re: Nested transactions and tuple header info

Alvaro Herrera wrote:
> On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
>
> > When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> > replace it with xmin=3. xid=3 will be marked as committed if xid2
> > aborts, and will be marked as aborted if xid3 commits.
> >
> > So, if xid2 aborts, the insert of xid1 should be honored, and xid3 is
> > marked as committed, and the opposite if xid2 commits.
>
> Ok, I've been looking at implementing this. However it just occurred to
> me that a transaction, different from the one modifying the tuple, could
> try to see its xmax.

First, I assume it isn't a problem to change the cmin because we have a
lock on the tuple while we are modifying it.

> Since the xmin signals the tuple as being updated concurrently by
> another transaction (it's in progress), this can only happen if the
> other transaction tries to read it using SnapshotDirty.

As far as someone trying to read the xmax when it isn't there, I assumed
we had a tuple bit set indicating we have xmin/cmin/cmax, and that the
outside transaction doesn't need to look up the xmax.

However, for ourselves, we need to look that phantom xid up in our local
memory and find the xmin/xmax for ourselves, right?

> One such possible caller is EvalPlanQual. It could go to sleep using
> XactLockTableWait() on the SnapshotDirty's xmax. But the tuple has
> something strange in its xmax -- it's the tuple's cmin actually.
> Leaving this would be probably a bug.

Again, the bit is set, everyone has to look up the phantom xid in their
own phantom xid list, or look in pg_subtrans to find out if they own
that xid, and if so, then lookup the xmin/xmax in their local memory.

As far as SnapshotDirty(), can you explain why that is used and if a
tuple being created in an open transaction is subject to that? I assume
it would be if we were updating a tuple and need to sleep on it. Can't
we use pg_subtrans to find the main transaction xid and sleep on that?
Once the main transaction is done, we then need to relook at the phantom
xid to see if it was marked as committed/aborted because it might not
match the main transactions status.

Sorry I didn't reply earlier. I had to think on this one.

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