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.
