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

Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> So I believe you're right, and we can skip taking the lock in the no
>> xid case - I actually think with just a little bit of more work, we
>> can go even further, and get rid of the ReadNewTransactionId() call
>> completely during snapshotting.
> 
> [ squint... ]  This goes a bit far for me.  In particular, I think this
> will fail in the edge case when there are no live XIDs visible in
> ProcArray.  You cannot go back and do ReadNewTransactionId afterward,
> at least not without re-scanning the ProcArray a second time, which
> makes it at best a questionable win.

Why would it? The idea was to remember the largest committed xid, and that
won't go away just because the proc array is rather empty xid-wise. Actually,
in that case the "largest comitted xid"+1 will (nearly) be what
ReadNewTransactionId() returns. (Nearly because the transaction with the xid
ReadNewTransactionId()-1 might have aborted, so largestCommittedXid might be
a bit further behind ReadNewTransactionId().)

(That slightly lagging of largestCommittedXid might cause some tuples not to
be VACUUMED though, so we might want to update largestCommittedXid for
ABORTS too, and probably rename it to largestNonRunningXid or whatever ;-) ).

I would go as far as saying that largestCommittedXid+1 is the natural choice
for xmax - after all, xmax is the cutoff point after which a xid *cannot*
be seen as committed, and largestCommittedXid+1 is the smallest xmax that
guarantees that we see xacts committed before the snapshot as committed.

The xmin computation won't change - apart from using some other initial value.

This would rid us of the rather complicated entanglement of XidGenLock and
the ProcArrayLock, lessen the lock contention, and reduce the average snapshot
size a bit.

greetings, Florian Pflug