Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> 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. > > You still don't see the point. Consider > > BEGIN; > DECLARE CURSOR c1 FOR SELECT * FROM a ...; > INSERT INTO a VALUES(...); -- call this row x > DECLARE CURSOR c2 FOR SELECT * FROM a ...; > BEGIN; > DELETE FROM a WHERE ...; -- assume this deletes row x > ROLLBACK; > FETCH FROM c1; -- must NOT see row x > FETCH FROM c2; -- must see row x > > AFAICS your proposal does not support this. The two cursors' snapshots > will differ only in the recorded current-cid for the outer transaction. > If the subtrans has overwritten xmin/cmin, there is no way to make that > decision correctly.
I do not overwrite cmin or cmax. If xid=1 creates a row: xmin=1 cmin=1 and xid=2 goes to expire it, we get: xmin=3 (phantom for xmin=1, xmax=2) cmin=1 cmax=1 and we set a phantom bit on the tuple. When we see it later and need to know the xmin or xmax, we look it up in local memory. (Maybe we don't even need a hash, just a List because I can't imagine more than a few of these phantoms being used.) Other backends see the tuple with a xmin as "in progress" so they don't need to look any further. Then, on commit, we decide if a tuple created by xid=1 and expired by xid=2 should appear created or not, and mark the phantom commit status accordingly. -- 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 6: Have you searched our list archives? http://archives.postgresql.org