On Tue, Nov 15, 2022 at 12:29 PM Andres Freund <and...@anarazel.de> wrote: > ... I strongly dislike latestCommittedXid. That seems at least as misleading > as latestRemovedXid and has the danger of confusion with latestCompletedXid > as you mention.
> How about latestAffectedXid? I get why you don't care for latestCommittedXid, of course, but the name does have some advantages. Namely: 1. Most conflicts come from PRUNE records (less often index deletion records) where the XID is some heap tuple's xmax, a committed-to-everybody XID on the primary (at the point of the original execution of the prune). It makes sense to emphasize the idea that snapshots running on a replica need to agree that this XID is definitely committed -- we need to kill any snapshots that don't definitely agree that this one particular XID is committed by now. 2. It hints at the idea that we don't need to set any XID to do cleanup for aborted transactions, per the optimization in HeapTupleHeaderAdvanceLatestRemovedXid(). Perhaps something like "mustBeCommittedCutoff" would work better? What do you think of that? The emphasis on how things need to work on the REDO side seems useful. -- Peter Geoghegan
