On Tue, Mar 29, 2022 at 12:22:21PM -0400, Robert Haas wrote: > It's not, though, because the original proposal was to change things > around so that the value of MaxBackends would have been reliable in > _PG_init(). If we'd done that, then extensions that are using it in > _PG_init() would have gone from being buggy to being not-buggy. But > since you advocated against that change, we instead committed > something that caused them to go from being buggy to failing outright. > That's pretty painful for people with such extensions. And IMHO, it's > *much* more legitimate to want to size a data structure based on the > value of MaxBackends than it is for extensions to override GUC values. > If we can make the latter use case work in a sane way, OK, although I > have my doubts about how sane it really is, but it can't be at the > expense of telling extensions that have been (incorrectly) using > MaxBackends in _PG_init() that we're throwing them under the bus. > > IMHO, the proper thing to do if certain GUC values are required for an > extension to work is to put that information in the documentation and > error out at an appropriate point if the user does not follow the > directions. Then this issue does not arise. But there's no reasonable > workaround for being unable to size data structures based on > MaxBackends.
FWIW I would be on board with reverting all the GetMaxBackends() stuff if we made the value available in _PG_init() and stopped supporting GUC overrides by extensions (e.g., ERROR-ing in SetConfigOption() when process_shared_preload_libraries_in_progress is true). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
