"Florian G. Pflug" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly