On Tue, May 3, 2022 at 10:43 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, May 3, 2022 at 11:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@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.