Hi, On 2022-03-26 15:22:03 +0800, Julien Rouhaud wrote: > On Fri, Mar 25, 2022 at 03:23:17PM -0700, Andres Freund wrote: > > > > I don't really understand. The issue that started this thread was bugs in > > extensions due to accessing MaxBackends before it is initialized - which the > > patch prevents. > > Well, the patch prevents accessing a 0-valued MaxBackends but doesn't do > anything to solve the original complaint. It's not like extensions won't need > to access that information during _PG_init anymore.
It resolves the pretty common bug that an extension breaks once it's used via s_p_l instead of loaded on-demand because MaxBackends isn't initialized in the s_p_l case. > And indeed, any third party code that previously needed to access what > MaxBackends is supposed to store should already be using that formula, and > the new GetMaxBackends() doesn't do anything about it. It couldn't rely on MaxBackends before. It can't rely on GetMaxBackends() now. You can see why I think that what you want is unrelated to the introduction of GetMaxBackends(). If we introduce a separate hook that allows to influence things like max_connections or whatnot we'd *even more* need a way to verify whether it's legal to access MaxBackends in that moment. > So all extensions will be as broken as before, except the few that were > using MaxBackends without realizing it's 0. And if those exist (there's > actually one) they're not that broken, probably because MaxBackend is only > used to request additional shmem, with wanted value small enough so that > it's compensated by the extra 100kB shmem postgres allocates. I don't think it's rare at all. Greetings, Andres Freund
