On Tue, May 3, 2022 at 10:43 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, May 3, 2022 at 11:45 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > > I have some desire here to see us solve this problem not just for > > > service providers, but for users in general. You don't have to be a > > > service provider to want to disallow SET work_mem = '1TB' -- you just > > > need to be a DBA on a system where such a setting will cause bad > > > things to happen. But, if you are a DBA on some random system, you > > > won't likely find a hook to be a particularly useful way of > > > controlling this sort of thing. > > > > Yeah, I think this is a more realistic point. I too am not sure what > > a good facility would look like. I guess an argument in favor of > > providing a hook is that we could then leave it to extension authors > > to try to devise a facility that's useful to end users, rather than > > having to write an in-core feature. > > RIght. The counter-argument is that if we just do that, then what will > likely happen is that people who buy PostgreSQL services from > Microsoft, Amazon, EDB, Crunchy, etc. will end up with reasonable > options in this area, and people who download the source code from the > Internet probably won't. As an open-source project, we might hope to > avoid a scenario where it doesn't work unless you buy something. On > the third hand, half a loaf is better than nothing.
Thanks Tom and Robert for your responses. How about we provide a sample extension (limiting some important parameters say shared_buffers, work_mem and so on to some "reasonable/recommended" limits) in the core along with the set_config_option_hook? This way, all the people using open source postgres out-of-the-box will benefit and whoever wants, can modify that sample extension to suit their needs. The sampe extension can also serve as an example to implement set_config_option_hook. Thoughts? Regards, Bharath Rupireddy.