On Sat, 2025-03-15 at 17:14 -0700, Gurjeet Singh wrote: > > One other difference in my version of the patch [0] is to call this GUC > > vacuum_truncate and have it apply to both autovacuum and VACUUM. I did > > this for the following reasons: > > +1 for the GUC name for the reasons you identified. But -1 for the behaviour > where the reloption and vacuum command's options overrides GUC. > > I'd like to bring our attention back to how this thread started. Will started > the discussion by asking for a way to disable autovacuum's truncate behaviour. > Even though the production outage he faced was due to manual vacuum, he was > worried about the same behaviour that autovacuum may cause, especially since > the > parameter old_snapshot_threshold is no longer available; > old_snapshot_threshold > allowed sysadmins like Will to disable the truncation behaviour globally. I > provided an anecdote where autovacuum's truncation behaviour had in fact > caused > a replication outage as well as the consequent application outage. > > The behaviour that is being proposed here does not prevent that situation from > arising again. A sysadmin who's trying to prevent replication outage and > a consequent application outage won't benefit from tuning vacuum_truncate GUC, > because a reloption or VACUUM (TRUNCATE) command will override its behaviour, > and lead to an outage. > > We want this new GUC to give the sysadmin the power to override the > per-relation > and per-command settings. > > > I guess what I'm looking for is a global switch that guarantees no relation > truncation will take place on the instance, so that the relevant replication > record is never emitted, and hence will never lead to a blocked replication on > the replica and never cause a consequent outage of applications connected to > the > replica(s).
Essentially, you are looking for something that reinstates the unintended side effect of "old_snapshot_threshold" that some people relied on. I understand your reasoning. What I am worried about, and why I am against that, is the POLA violation this constitutes. I PostgreSQL, there usually are global settings that can be overridden by per-relation settings. Doing it differently here would surprise and confuse many users. This is not the only way a user can do damage to the system by overriding the administrator's settings. Users can override all autovacuum settings and even disable autovacuum on a table. I don't think these settings are less dangerous than VACUUM truncation. Yours, Laurenz Albe
