Re: Configuration Parameter/GUC value validation hook

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Euler Taveira <euler(at)eulerto(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Configuration Parameter/GUC value validation hook
Date: 2022-05-09 13:17:44
Message-ID: CA+TgmoZMkQ5xcw2kqEh0G9FHrGrNCMkoTivUkcBFop+pdAzuHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 9, 2022 at 3:44 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> Thanks for providing thoughts. I'm personally not in favour of adding
> any new syntax, as the new syntax would require some education and
> changes to other layers. I see some downsides with new syntax:
> 1) It will be a bit difficult to deal with the parameters that don't
> have ranges (as pointed out by Robert upthread).
> 2) It will be a bit difficult to enforce platform specific
> configurations at run time - (say the user has scaled-up the host
> system/VM, now has more vcores, RAM and now they will have more memory
> and number of workers to use for their setting).
> 3) If someone wants to disallow users setting some core/extension
> configuration parameters which can make the server unmanageable (block
> setting full_page_writes to off, zero_damaged_pages to on, fsync to
> off, log levels to debug5, huge_pages to on, all the command options
> (archive_command, restore_command .... etc.).
>
> IMO, the hook and a sample extension in the core helps greatly to
> achieve the above.

I don't think that any of these are very fundamental objections. Every
feature requires education, many require changes to various layers,
and the fact that some parameters don't have ranges is a topic to
think about how to handle, not a reason to give up on the idea. (2)
may mean that some users - large service providers, in particular -
prefer the hook to the SQL syntax, but that's not a reason not to have
SQL syntax. (3) basically seems like an argument that people my do
dumb things with it, but that's true of every feature.

I'm not sure that a hook and sample extension is unacceptable; it
might be fine. But I think it is not saying anything other than the
truth to say that this will benefit large service providers while
leaving the corresponding problem unsolved for ordinary end users. And
I remain of the opinion that that's not great.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-05-09 13:23:47 Re: Mark all GUC variable as PGDLLIMPORT
Previous Message Bharath Rupireddy 2022-05-09 13:17:20 Re: Can postgres ever delete the recycled future WAL files to free-up disk space if max_wal_size is reduced or wal_recycle is set to off?