Hi all, When a table’s age reaches vacuum_failsafe_age, VACUUM enters failsafe mode and bypasses nonessential throttling such as autovacuum_vacuum_cost_delay so it can make progress as aggressively as possible.
However, if VACUUM’s freeze horizon is blocked by an old transaction, the failsafe behavior alone cannot reduce the table age. In that case, VACUUM may run at full speed but still be unable to advance relfrozenxid. I have an experimental patch to explore handling this situation. The patch adds a GUC, vacuum_freeze_terminate_blockers_pid, which allows VACUUM to terminate regular client backends whose transaction horizon blocks VACUUM from advancing its freeze cutoff. The intended targets are idle-in-transaction sessions and long-running active transactions that are holding an old xmin or assigned XID. One possible question is why not rely on idle_in_transaction_session_timeout. In practice, this parameter is often not configured, and even when it is, it only addresses idle-in-transaction sessions. It does not help with active long-running transactions that can also hold back VACUUM’s freeze horizon. The patch deliberately does not try to handle other causes of freeze horizon retention, such as replication slots, hot standby feedback, or prepared transactions. This is experimental and intended for discussion.
vacuum_freeze_terminate_blockers_pid.patch
Description: Binary data
