Re: vacuum_truncate configuration parameter and isset_offset - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: vacuum_truncate configuration parameter and isset_offset
Date
Msg-id Z-GLN06DlD8p737q@nathan
Whole thread Raw
In response to Re: vacuum_truncate configuration parameter and isset_offset  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: vacuum_truncate configuration parameter and isset_offset
Re: vacuum_truncate configuration parameter and isset_offset
List pgsql-hackers
On Mon, Mar 24, 2025 at 05:00:51PM +0100, Álvaro Herrera wrote:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff).  That would require
> no new mechanism.

I explained my reasons for not proceeding with that approach upthread [0].

I don't think there are any existing reloptions where there are two ways to
say "use the GUC."  For ones with corresponding GUCs, unsetting the storage
parameter is the mechanism for doing so.  vacuum_index_cleanup's AUTO
option would be the closest thing, but there's no backing GUC, so the
meaning of AUTO doesn't change unless someone changes the code.

TBH I'm not understanding the pushback for adding a way to determine
whether the storage parameter is actually set.  It's very simple, and it
seems like it could be useful elsewhere.  But more importantly, it allows
us to more closely match the behavior of the existing reloptions with GUCs,
and it prevents type mismatches (e.g., the reloption is an enum but the GUC
is a Boolean).

[0] https://postgr.es/m/Z-Fvmnf57z6zM8Ky%40nathan

-- 
nathan



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Next
From: Nikolay Shaplov
Date:
Subject: Re: vacuum_truncate configuration parameter and isset_offset