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
