Horton

Re: vacuum_truncate configuration parameter and isset_offset

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Nikolay Shaplov <dhyan@nataraj.su>, Robert Haas <robertmhaas@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@lists.postgresql.org, Robert Treat <rob@xzilla.net>, Fujii Masao <masao.fujii@oss.nttdata.com>, Albe <laurenz.albe@cybertec.at>, Gurjeet Singh <gurjeet@singh.im>, Will Storey <will@summercat.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-03-24T16:29:48Z
Lists: pgsql-hackers 
On Mon, Mar 24, 2025 at 9:08 AM David G. Johnston <
david.g.johnston@gmail.com> wrote:

> On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera <alvherre@alvh.no-ip.org>
> wrote:
>
>> Hello
>>
>> 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.
>>
>>
> That reloption is already an enum and there is no GUC to defer to when the
> value is unset.  It doesn't seem like an equivalent scenario.  AUTO is a
> perfectly useful value as opposed to an undocumented sentinel for
> unset/missing.
>
>
Sorry, the "already an enum" comment is wrong - I see the commit now where
we basically re-implemented boolean value processing logic and added an
"auto" option.

Basically we'd do this to make a boolean-compatible enum adding an
undocumented value "null" as a valid and default set value and then
interpret "null" as meaning "go use the vacuum_truncate GUC".

It's too late to argue against sentinel values so I suppose this would have
to be acceptable.

David J.