Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
