Re: pgsql: Add vacuum_truncate configuration parameter.

On Sat, 22 Mar 2025 at 05:40, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> 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
ofzero to disable something, and probably should be prohibited. 

Can you explain what does not make sense about it?  We have plenty of
GUCs and reloptions where -1 means "inherit the setting from somewhere
else". Do those also not make sense, or is this one somehow different?

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

The reason I was pointing this out is that I wanted to ensure that
this was considered before we release code with the new GUC. It's true
removing a GUC isn't as hard as removing a reloption and we already
have the reloption. If everyone thinks we'll likely not need
user-tunable options to specify the number of pages required before
truncation occurs then that's fine.  The problem I see is that we
already have lots of GUCs and it'd be nice not to have semi-redundant
ones in the future because we've failed to consider something.  I was
just pointing out the "something" part that we might want to consider.

David