From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Will Storey <will(at)summercat(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disabling vacuum truncate for autovacuum |
Date: | 2025-03-16 05:29:17 |
Message-ID: | 6f2f2167f4be09e6ca9251c8f69dfe01809d68be.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastien Flaesch | 2025-03-16 09:30:02 | Re: After upgrading libpq, the same function(PQftype) call returns a different OID |
Previous Message | Gurjeet Singh | 2025-03-16 00:14:14 | Re: Disabling vacuum truncate for autovacuum |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-03-16 05:39:48 | Re: Add contrib/pg_logicalsnapinspect |
Previous Message | Michael Paquier | 2025-03-16 02:45:38 | Re: Dubious server log messages after pg_upgrade |