Re: vacuum_truncate configuration parameter and isset_offset

On Mon, Mar 24, 2025 at 5:42 AM Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:

> В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь
> Nikolay
> Shaplov написал:
>
> > PS. I've just looked at code for vacuum_index_cleanup it has very same
> > logic, just replace "auto" with anything you like, and uses enum.
> > Grep for StdRdOptIndexCleanupValues for more info
>
> I thought about it a bit more...
>
> ALTER TABLE test SET (vacuum_truncate);
> ALTER TABLE test SET (vacuum_truncate=false);
> ALTER TABLE test RESET (vacuum_truncate);
>
> Nobody will ever guess that these are three different cases.
>
> since for enum solution
> ALTER TABLE test SET (vacuum_truncate=on);
> ALTER TABLE test SET (vacuum_truncate=off);
> ALTER TABLE test SET (vacuum_truncate=unset);
> ALTER TABLE test RESET (vacuum_truncate);
>
>
Actually, we'd want to prohibit vacuum_truncate=unset (or whatever internal
enum option value we choose) as input since none of the other reloptions
allow the user to specify the sentinel value but instead require the use of
reset to achieve it.

i.e., the reset value for parallel_workers is -1:

{
"parallel_workers",
"Number of parallel processes that can be used per executor node for this
relation.",
RELOPT_KIND_HEAP,
ShareUpdateExclusiveLock
},
-1, 0, 1024

but:

alter table vct set (parallel_workers=-1);
ERROR: value -1 out of bounds for option "parallel_workers"
DETAIL: Valid values are between "0" and "1024".

So, given the precedent of vacuum_index_cleanup and the above, we should
turn this into an enum that accepts all existing boolean literal inputs and
also has a undocumented "unset" default value that the user is not allowed
to explicitly set but instead only gets used to resolve an unset reloption
at runtime.

David J.