Re: A small mistake in the initial latestCompletedXid idea

"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> Therefore, I suggest that we rename latestCompletedXid to latestCommittedXid,
> and update it only on commits. Admittedly, this won't bring any measurable
> performance benefit in itself (it will slightly reduce the average snapshot
> size, though), but not doing so might stand in the way of possible future
> optimizations in that area.

This is a bad idea. As you say, it doesn't directly save anything,
and the downside is that it may result in RecentGlobalXmin not moving
forward. Consider a situation where there's a long string of aborts and
nary a commit. latestCommittedXid won't advance, therefore each new
transaction continues to compute xmin = xmax = latestCommittedXid+1,
and so the window between global xmin and the newest active XIDs gets
wider and wider. That puts performance stress on pg_clog and
pg_subtrans buffers --- if it goes on long enough, we get into a context
swap storm caused by pg_subtrans buffer thrashing. We need to be sure
that xmin/xmax move forward when XIDs exit the ProcArray, whether they
commit or not.

Your post made me think for awhile about whether we really need to
serialize aborts at all. From a transactional correctness standpoint
I think maybe we don't, but again the difficulty is with xmin tracking.
If an aborting xact can remove its XID from ProcArray without locking,
then it is possible that two concurrent scans of ProcArray arrive at
different xmin values, which means that GetOldestXmin might deliver
an incorrectly large answer, and that's fatal. (One of the possible
consequences is truncating pg_subtrans too soon, but I believe there
are other ones too.)

Subtransactions don't affect xmin, of course, so there may be an
argument here that we don't have to do this stuff for a subtransaction
abort. But I remain unconvinced that optimizing subtransaction abort
will really buy a performance gain worth taking any risk for.

regards, tom lane