Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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
> DECLARE CURSOR c1 FOR SELECT * FROM a ...;
> INSERT INTO a VALUES(...); -- call this row x
> DECLARE CURSOR c2 FOR SELECT * FROM a ...;
> DELETE FROM a WHERE ...; -- assume this deletes row x
> 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:
and xid=2 goes to expire it, we get:
xmin=3 (phantom for xmin=1, xmax=2)
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
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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2004-06-02 14:46:02|
|Subject: Re: Converting postgresql.conf parameters to kilobytes |
|Previous:||From: Tom Lane||Date: 2004-06-02 14:37:31|
|Subject: Re: ACLs versus ALTER OWNER |