Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> You can't change xmin --- this would break visibility tests.
>
> > 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.
>
> That would be fine if the shorthand were readable, but it's not.
>
> > A cursor looking at the rows has to recognize the xid is a phantom (via
> > pg_subtrans) and look up the creation xid.
>
> And it will find that how? Imagine that the creating transaction is
> itself a subtransaction, and the deleting one is a few nesting levels
> further down. I don't see how the tuple is going to carry enough
> information to let you determine what's what, if the deleting subxact
> overwrites the creating one's XID.
The backend who created _and_ expired the tuple has to do a lookup to
find the creation or expire xid.
We need two things. First, we need to control the visibility of the
tuple once the entire transaction is done. This does that.
Second, we need to be able to find the creation and expire xid, and that
information is only required to be visible by the main transation and
its subtransactions. On commit we can adjust these xid status to show
the proper visibility.
How do they do the lookup? Well, one idea would be to just create a
local backend hash of these xids and their creation/expire xids.
Another idea is that pg_subtrans already points to a parent xid. We
could use the same method and point to both creation and expire xids.
Why does this not work?
-- 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