Re: XMIN semantic at peril ?

On Thu, Oct 11, 2007 at 01:48:10PM -0400, Tom Lane wrote:

> > If the query is always based on a primary key + XMIN,
It is.

> > and since
> > vacuum is the only thing that sets FrozenTransactionId, would it be
> > unsane to change the update to
>
> > - update row with "... where pk=... and XMIN IN (old_xmin_from_read,
> > FrozenTransactionId)
>
> I wouldn't risk it, because that *would* fail in the case Karsten
> mentioned of an update sequence taking so long that a concurrent
> update got frozen.

Which is the failure case we should be more worried about:
"not detecting a valid collision" rather than "detecting a
non-collision" as could happen in the scenario Tom pointed
out. False-Negative vs. False-Positive, that is to say ;-)

I was unable to find any reference to FrozenTransationId in
the 8.2 documentation (found it in the source, though).
Hence one would assume its value cannot be derived (at the
SQL level) at runtime and hence it needed to be hardcoded in
our Python code. Which, I dare say, would mean relying on
even more obscure implementation details which was part of
the argument that triggered the whole process of thought.

Ne'ertheless, thanks for the suggestion. I am gaining a much
better understanding of the factors involved.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346