Re: Use latestCompletedXid to slightly optimize TransactionIdIsInProgress

"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> Since we already advance latestCompletedXid on subtransaction and toplevel
> transaction aborts, we might as well use the value to rule out surely
> in-progress transctions at the top of TransactionIdIsInProgress.

This patch bothers me a bit, because TransactionIdIsInProgress has
always been defined to return "true" only for XIDs that it can
positively confirm are active; not, for instance, transactions that
haven't started yet. However, I can't actually see any big downside
to changing it as you suggest. The only bad consequence I can think
of offhand is that VACUUM could see an already-wrapped-around tuple
as INSERT_IN_PROGRESS rather than committed, which would stop it from
freezing the tuple, which would break a behavior that people have
sometimes used to get out of transaction wraparound situations.
But we should now have enough defenses in there to prevent such
problems from happening in the first place; and anyway the VACUUM trick
would still work, except in the very-improbable case that the tuple's
XMIN_COMMITTED bit had never gotten set before it wrapped around.

There is one serious bug in the patch as proposed: you can't examine
latestCompletedXid without acquiring the ProcArrayLock. In a
multiprocessor that requires memory fence instructions, it would be
entirely possible to deliver a wrong answer as a consequence of reading
a stale value of latestCompletedXid. (We execute fence instructions
when acquiring/releasing locks.) However, after the recent rewrite of
TransactionIdIsInProgress, we can put the check after taking the lock
without added complexity.

Hence, applied with revisions.

regards, tom lane