Re: Nested transactions and tuple header info

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
DELETE a; 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(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