public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Rowley <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
Date: Mon, 24 Mar 2025 11:22:43 +1300
Message-ID: <CAApHDvoGP9kRZNOq7QbqD2ierrCGubQ37oDM8xkgX2zbBou7HA@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CAApHDvo9E+imdCrOjhx00unxxDYox=7fr2+ATfyEw86iRwy3AA@mail.gmail.com>
	<CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA@mail.gmail.com>

On Sat, 22 Mar 2025 at 05:40, David G. Johnston
<[email protected]> 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

view thread (6+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
  In-Reply-To: <CAApHDvoGP9kRZNOq7QbqD2ierrCGubQ37oDM8xkgX2zbBou7HA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox