Re: make MaxBackends available in _PG_init
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, "Bossart,
Nathan" <bossartn@amazon.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, "wangsh.fnst@fujitsu.com" <wangsh.fnst@fujitsu.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Greg Sabino Mullane <htamfids@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-12T19:12:42Z
Lists: pgsql-hackers
On Tue, Apr 12, 2022 at 2:03 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > On Tue, Apr 12, 2022 at 10:44:27AM -0700, Andres Freund wrote: > > On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote: > >> Here's a new patch set. I've only changed 0003 as described above. My > >> apologies for the unnecessary round trip. > > > > ISTM we shouldn't apply 0002, 0003 to master before we've branches 15 off.. > > That seems reasonable to me. Gah, I hate putting this off for another year, but I guess I'm also not convinced that 0003 has the right idea, so maybe it's for the best. Here's what's bugging me: 0003 decrees that _PG_init() is the Wrong Place to Adjust GUC Settings. Now, that begs the question: what is the right place to adjust GUC settings? I argued upthread that extensions shouldn't be overriding values from postgresql.conf at all, but on further reflection I think there's at least one legitimate use case for this sort of thing: some kind of auto-tuning module that, for example, looks at how much memory you have and sets shared_buffers or work_mem or something based on the result. It's arguable how well something like this can actually work, but we probably shouldn't try to prevent people from doing it. I'm a little less clear why Citus thinks this is an appropriate thing for it to do, vs. telling the user to configure a useful value, and I'd be curious to hear an explanation around that. But if there's even one use case where adjusting GUCs at this phase is reasonable, then 0003 isn't really good enough. We need an 0004 that provides a new hook in a place where such changes can safely be made. Meanwhile, committed 0001. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Add a new shmem_request_hook hook.
- 4f2400cb3f10 15.0 landed
-
Remove non-functional code for unloading loadable modules.
- ab02d702ef08 15.0 landed
-
Fix misleading comments about background worker registration.
- 701d918a426b 15.0 landed
-
Revert the addition of GetMaxBackends() and related stuff.
- 7fc0e7de9fb8 15.0 landed
-
Fix typo in multixact.c
- 0147fc7c8c92 15.0 landed
-
Reduce more the number of calls to GetMaxBackends()
- 4567596316d1 15.0 landed
-
Remove MaxBackends variable in favor of GetMaxBackends() function.
- aa64f23b0292 15.0 landed
-
Fix comments about bgworker registration before MaxBackends initialization
- 5ecd0183fb6a 15.0 landed
-
Fix bogus assertion in BootstrapModeMain().
- e12694523e7e 15.0 cited
-
Make sure MaxBackends is always set
- dfbba2c86cc8 9.3.0 cited