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.
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.
regards, tom lane
