public inbox for [email protected]  

help / color / mirror / Atom feed

From: Laurenz Albe <[email protected]>
To: Gurjeet Singh <[email protected]>
To: Nathan Bossart <[email protected]>
To: Andres Freund <[email protected]>
To: Will Storey <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Postgres Hackers <[email protected]>
Subject: Re: Disabling vacuum truncate for autovacuum
Date: Sun, 16 Mar 2025 06:29:17 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABwTF4WFp-oNSm6utik6g-1HZBxijTJBcuX7BKD8MYqza+KMnw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CABwTF4U3xkF=ZRi2pztUDxohoN8h6XL10=QmTtuTXoMjzu5-zg@mail.gmail.com>
	<[email protected]>
	<CA+TgmoZMXN19eorKdeiiFCv3AJFVaUAfkzRuamnt8A9U8uJSqg@mail.gmail.com>
	<Z7Tl2d7HrG1AQEOc@nathan>
	<CABwTF4XPc1_y=khhjErd=Oz8R20ZH05KigiAnMjjA+028QbohQ@mail.gmail.com>
	<Z8H-tHaYZ37lVZHb@nathan>
	<[email protected]>
	<Z9ROT9v4rHjDYWNX@nathan>
	<CABwTF4WFp-oNSm6utik6g-1HZBxijTJBcuX7BKD8MYqza+KMnw@mail.gmail.com>

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

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Disabling vacuum truncate for autovacuum
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox