Re: vacuum_truncate configuration parameter and isset_offset

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

> > but I don't think it's more
> > confusing here than for other vacuum reloptions. I have seen people
> > try to unset vacuum reloptions by using SET to configure them to the
> > default value rather than by using RESET to remove them. But then
> > later they change the system default and that table is still nailed to
> > the old default. I always find myself slightly bemused by this,
> > because it doesn't seem that hard to me to figure out how it actually
> > works, but it's definitely a real issue. However, I don't see why the
> > issue is any more acute for this parameter than any other, and it
> > certainly does not seem like a good idea to make this parameter work
> > differently from the other ones.
>
> May be I can agree with you. But this does not explain why we should
> switch
> boolean from two possible values into three... It can't have three values
> for
> any practical reason. This should not be boolean anymore in this case.
>
>
The boolean is two-valued. The state of the reloption is also binary - set
or unset (i.e., it is listed in pg_class.reloptions, or not). In the unset
state the effective value of a reloption comes from the corresponding GUC
(or, lacking that, some hard-coded default). If set, the value comes from
the associated boolean. RESET places a reloption into the unset state.

David J.