Re: PL/pgSQL bug?

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