On Sat, 22 Mar 2025 at 05:40, David G. Johnston <david.g.johns...@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 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
