Re: pgsql: Add vacuum_truncate configuration parameter.

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.

From [2], it seems there are people around unhappy with the current
compile-time settings. If we do end up making those user configurable,
then we're going to have a redundant "vacuum_truncate" reloption and a
redundant GUC.

David

[1] https://postgr.es/m/CAApHDvrfngqCpQ09LKdr-BnJEVHW0%3DwAhxfRBnw%3DHJ2645cJPg%40mail.gmail.com
[2] https://postgr.es/m/CA%2BYyo5Trs9x03-sc4PpmEXPY9K_B_jbEbNd01RbF%2BvOxs3zVUA%40mail.gmail.com