On Tue, Aug 2, 2022 at 4:12 PM Peter Geoghegan <p...@bowt.ie> wrote: > That is, we only need to make sure that the "multiXactCutoff must > always be <= oldestMxact" invariant holds once, by checking for it > directly. The same thing happens with OldestXmin/FreezeLimit. That > seems like a simpler foundation. It's also a lot more logical. Why > should the cutoff for freezing be held back by a long running > transaction, except to the extent that it is strictly necessary to do > so to avoid wrong answers (wrong answers seen by the long running > transaction)?
Anybody have any input on this? I'm hoping that this can be committed soon. ISTM that the way that we currently derive FreezeLimit (by starting with OldestXmin rather than starting with the same ReadNextTransactionId() value that gets used for the aggressiveness cutoffs) is just an accident of history. The "Routine vacuuming" docs already describe this behavior in terms that sound closer to the behavior with the patch than the actual current behavior: "When VACUUM scans every page in the table that is not already all-frozen, it should set age(relfrozenxid) to a value just a little more than the vacuum_freeze_min_age setting that was used (more by the number of transactions started since the VACUUM started)" Besides, why should there be an idiosyncratic definition of "age" that is only used with vacuum_freeze_min_age/vacuum_multixact_freeze_min_age? Why would anyone want to do less freezing in the presence of a long running transaction? It simply makes no sense (unless we're forced to do so to preserve basic guarantees needed for correctness, such as the "FreezeLimit <= OldestXmin" invariant). -- Peter Geoghegan
