Re: pgsql: Add vacuum_truncate configuration parameter.

On Thu, Mar 20, 2025 at 4:07 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Fri, 21 Mar 2025 at 04:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Nathan Bossart <nathan(at)postgresql(dot)org> writes:
> > > Since there's presently no way to determine whether a Boolean
> > > storage parameter is explicitly set or has just picked up the
> > > default value, this commit also introduces an isset_offset member
> > > to relopt_parse_elt.
> >
> > Uh, what? Why is it a good idea to distinguish those states?
> > Seems like that risks some very surprising behavior, ie if the
> > default is "true", why shouldn't that act exactly like an
> > explicit setting of "true"?
>
> I was thinking about this yesterday as the topic of a
> user-configurable options for truncation threshold came up in [1]. I
> find it a bit annoying the boolean vacuum_truncate reloption was added
> (a few years ago) as we could have instead added a more flexible
> truncate_scale_factor that could be set to -1 to disable truncation.
> Maybe it's too late now as reloptions are not easy to remove. Adding
> this GUC now does put us a bit further down the path of the boolean
> option.

Not seeing much point in trying to get rid of the on/off switch. It just
won't make sense to choose a tunable value of zero to disable something,
and probably should be prohibited.

I'm seeing an implementation detail discussion here, not a behavior one.
The field complaint that we don't let the DBA control this at the GUC level
is valid and reasonably solved. The "default" behavior hasn't changed but
now instead of hard-coding the default we moved it to a GUC. The storage
parameter is no longer documented as having a default, which is correct.
It now behaves like most of the other storage parameters in that if unset a
GUC provides the value.

David J.