Re: Nested transactions and tuple header info

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >     BEGIN;    xid=1
> >     INSERT a;
> >     BEGIN;    xid=2
> >     INSERT b;
> >     DELETE a; xid=3
> >     COMMIT;
> >     COMMIT;
> 
> > When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> > replace it with xmin=3.
> 
> You can't change xmin --- this would break visibility tests.  Consider
> a cursor opened in the outer transaction after the INSERT a.  It should
> be able to see the "a" row (note that this depends on recognizing xid
> equality and then comparing cid's within the outer transaction).  If the
> subtransaction mangles xmin then it is no longer possible to make this
> test correctly.
> 
> This is exactly the same argument as not being able to overwrite cmin.

Basically the phantom xid's are a shorthand for saying the tuple was
created by xid1 and deleted by xid2, both part of the same main
transaction.

A cursor looking at the rows has to recognize the xid is a phantom (via
pg_subtrans) and look up the creation xid.

Also, we will need a phantom xid for every xid1/xid2 pair.  You can't
just create one phantom xid per subtransaction because you must be able
to control independently commit/rollback rows based on the status of the
insert transaction.

In this case:
BEGIN;    BEGIN;    xid=1    INSERT a;        BEGIN;    xid=2        INSERT b;            BEGIN;    xid=3
DELETEa; xid=4            DELETE b; xid=5            COMMIT;        COMMIT;    COMMIT;COMMIT;
 

xid4 and xid5 has to be adjusted based on that status of xid1 and xid2.

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