Re: Disabling vacuum truncate for autovacuum

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Robert Treat <rob(at)xzilla(dot)net>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Andres Freund <andres(at)anarazel(dot)de>, Will Storey <will(at)summercat(dot)com>, 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-17 15:14:51
Message-ID: Z9g8a4HGLUcSo96v@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Sun, Mar 16, 2025 at 06:24:59PM -0400, Robert Treat wrote:
> So if the general idea is a guc "vacuum_truncate" which sets a global
> default for whether vacuums and autovacuums should do truncation, and
> we then have the storage parameter which would override the global
> setting. And to be clear, there is also the decision on whether the
> VACUUM commands default should default to truncate=on (like the
> existing behavior) or truncate == vacuum_truncate guc, unless
> explicitly set. I think the latter is probably the right way to go.

Thank you all for the discussion. I've attempted to address the
outstanding feedback into the new version of the patch.

--
nathan

Attachment Content-Type Size
v4-0001-Add-vacuum_truncate-configuration-parameter.patch text/plain 11.1 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2025-03-17 15:18:13 Re: Creating a new database on a different file system
Previous Message Sylvain Cuaz 2025-03-17 14:57:04 Restoring only a subset of schemas

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2025-03-17 15:17:03 Re: Incorrect result of bitmap heap scan.
Previous Message David G. Johnston 2025-03-17 15:09:12 Re: Forbid to DROP temp tables of other sessions