From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, David Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Nested transactions and tuple header info |
Date: | 2004-06-02 15:12:31 |
Message-ID: | 24590.1086189151@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I don't understand why a single counter is needed for phantom xids. We
> keep the cmin/cmax on the tuple already, and our own backend can look up
> the xmin/xmax that goes with the phantom.
Oh, so you're thinking of an internal table that provides a mapping back
to the replaced xmin? Ugh. Perhaps it could be made to work, but it's
a lot of mechanism, and it will slow down visibility checks (since
AFAICS you'd have to check every subxid against the phantoms table).
If we go with a global CID counter then we don't have to add that step.
A global CID counter would also simplify other visibility tests. Alvaro
hasn't said anything about how he's doing visibility checks across
different subxacts of the same main xact, but without global CID there
would need to be some pretty ugly checks to determine whether a subxact
happened before or after the CID cutoff your outer xact is interested
in.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-06-02 15:13:38 | Re: ACLs versus ALTER OWNER |
Previous Message | Tom Lane | 2004-06-02 15:05:43 | Re: Converting postgresql.conf parameters to kilobytes |