Hi, On 2022-11-16 14:14:30 -0800, Peter Geoghegan wrote: > /* > - * If 'tuple' contains any visible XID greater than latestRemovedXid, > - * ratchet forwards latestRemovedXid to the greatest one found. > - * This is used as the basis for generating Hot Standby conflicts, so > - * if a tuple was never visible then removing it should not conflict > - * with queries. > + * Maintain snapshotConflictHorizon for caller by ratcheting forward its > value > + * using any committed XIDs contained in 'tuple', an obsolescent heap tuple > + * that caller is in the process of physically removing via pruning. > + * (Also supports generating index deletion snapshotConflictHorizon values.)
The "(also...) formulation seems a bit odd. How about "an obsolescent heap tuple that the caller is physically removing, e.g. via HOT pruning or index deletion." or such? > + * snapshotConflictHorizon format values are how all hot Standby conflicts > are > + * generated by REDO routines (at least wherever a granular cutoff is used). Not quite parsing for me. > + * Caller must initialize its value to InvalidTransactionId, which is > generally > + * interpreted as "definitely no need for a recovery conflict". > + * > + * Final value must reflect all heap tuples that caller will physically > remove > + * via the ongoing pruning operation. ResolveRecoveryConflictWithSnapshot() > is > + * passed the final value (taken from caller's WAL record) by a REDO routine. > + /* > + * It's quite possible that final snapshotConflictHorizon value will be > + * invalid in final WAL record, indicating that we definitely don't > need to > + * generate a conflict > + */ *the final Isn't this already described in the header? > @@ -3337,12 +3337,17 @@ GetCurrentVirtualXIDs(TransactionId limitXmin, bool > excludeXmin0, > * GetConflictingVirtualXIDs -- returns an array of currently active VXIDs. > * > * Usage is limited to conflict resolution during recovery on standby > servers. > - * limitXmin is supplied as either latestRemovedXid, or InvalidTransactionId > - * in cases where we cannot accurately determine a value for > latestRemovedXid. > + * limitXmin is supplied as either a snapshotConflictHorizon format XID, or > as > + * InvalidTransactionId in cases where caller cannot accurately determine a > + * safe snapshotConflictHorizon value. > * > * If limitXmin is InvalidTransactionId then we want to kill everybody, > * so we're not worried if they have a snapshot or not, nor does it really > - * matter what type of lock we hold. > + * matter what type of lock we hold. Caller must avoid calling here with > + * snapshotConflictHorizon format XIDs that were set to InvalidTransactionId What are "snapshotConflictHorizon format XIDs"? I guess you mean format in the sense of having the semantics of snapshotConflictHorizon? Greetings, Andres Freund
