Re: Low hanging fruit in lazy-XID-assignment patch?

Tom Lane wrote:
> Here's some revised text for the README file, based on using Florian's idea
> of a global latestCompletedXid variable. As I worked through it I realized
> that in this design, XidGenLock gates entry of new XIDs into the ProcArray
> while ProcArrayLock gates their removal. Which is an interesting sort of
> symmetry property. It also turns out that the reason we need to gate entry
> with XidGenLock is to keep from breaking GetOldestXmin, rather than to ensure
> correctness of snapshots per se.
I believe it would break both, no? If an xid <= latestCompletedXid is
not included in the snapshot, but later used for updates, the snapshot
will see those changes as committed when they really are not.

But other than that, it really sounds fine. It certainly explains things much
better than the comments in the existing code.

I noticed two rather cosmetic issues
.) latestCompletedXid sounds as it might refer to the *last* completed xid,
but it actually refers to the largest / highest completed xid. So maybe we
should call it highestCompletedXid or largestCompletedXid.

.) Since you mention that we assume reading and writing int4s are atomic
operations, maybe we should mention that for safety's sake we mark the
corresponding pointers with volatile?

greetings, Florian Pflug