Re: pgsql: Add vacuum_truncate configuration parameter.

On Sat, 22 Mar 2025 at 05:40, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)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 of zero 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 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.

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