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
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? |