Configuration Parameter/GUC value validation hook

Hi,

Right now postgres can't prevent users setting certain configuration
parameters or GUCs (like shared_buffers, temp_buffers, work_mem,
maintenance_work_mem, max_stack_depth, temp_file_limit,
max_worker_processes, other worker processes settings,
effective_io_concurrency and so on) to unreasonable values, say
shared_buffers to 80% of available memory. What happens is that the
server comes up initially and but soon it ends up crashing or some
other PANICs or errors. IMO, we all have to agree with the fact that
the users setting these parameters aren't always familiar with the
consequences of unreasonable values and come to the vendors to bring
back their server up after it crashed and went down. Mostly, these
parameters, that worry the vendors, are some or the other way
platform/Virtual Machine configuration (vcores, RAM, OS, disk)
dependent and vary offering to offering. Of course, each postgres
vendor can implement their own solution in their control plane or
somewhere in the service stack before allowing users to set these
values, but that involves looking at the parameters and their type
which isn't good from maintainability and extensibility (if the server
adds a new GUC or changes data type of a certain parameter)
perspective and it might be difficult to do it right as well.

Is there any hook or a way in postgres today, to address the above
problem? One way, I can think of to use is to have a
ProcessUtility_hook and see if the statement is T_AlterSystemStmt or
T_VariableSetStmt or T_AlterDatabaseSetStmt or T_AlterRoleSetStmt type
and check for the interested GUC params and allow or reject based on
the value (but we might have to do some extra stuff to know the GUC
data type and parse the value). And this solution doesn't cover
extensions setting the server GUCs or custom GUCs.

I propose to add a simple new hook in set_config_option (void
set_config_option_hook(struct config_generic *record);) and the
vendors can implement their own platform-dependent extensions to
accept or reject certain parameters (based on platform/VM
configuration) that are of interest to them.

Thoughts?

Regards,
Bharath Rupireddy.