Tom Lane wrote:
>
> Hannu Krosing <hannu@tm.ee> writes:
> > Tom Lane wrote:
> >> That's what the docs presently say, but they're in error --- nonzero
> >> xmax could represent a not-yet-committed deleting xact (or one that
> >> did commit, but not in your snapshot); or it could be from a deleting
> >> xact that rolled back.
>
> > or it can come from referential integrity triggers:
>
> Mmm, yeah, SELECT FOR UPDATE uses xmax to record the identity of a
> transaction that has a row locked for update. In this case the xact
> hasn't actually deleted the old row yet (and may never do so), but xmax
> is set as though it has.
>
> > Now I have a question: if xmax is not used in determining tuple
> > visibility (as I had assumed earlier) then what is ?
>
> There are additional status bits in each tuple (t_infomask) that
> distinguish these various situations. The xmax field alone doesn't
> tell you much, since you can't interpret it without context.
As I understood it it should tell the trx id that invalidated this
tuple, no ?
If you must write t_infomask in the tuple anyhow, then why not clean up
xmax
on abort ?
> I'm not sure why we bother to make xmin/xmax/etc visible to
> applications. They're really of no value to an app AFAICS.
>
I guess they used to be of value at the time when time travel was
possible
and people did use xmax for documented purposes, i.e. recording tuple's
lifetime
and not for "other" stuff, especially without cleaning up after trx
abort ;)
I agree that they are losing their utility as we are moving away from
the
original notion of transaction ids (and oids) as something permanent
that could
be used for time travel or system auditing and recommending peole who
need such
features to reimplement those at application level, with triggers and
explicitly
defined fields.
------------------
Hannu