On Fri, Jan 7, 2022 at 1:09 PM Bossart, Nathan <bossa...@amazon.com> wrote: > I wouldn't be surprised to learn of other cases, but I've only > encountered this specific issue with MaxBackends. I think MaxBackends > is notable because it is more likely to be used by preloaded libraries > but is intentionally initialized after loading them. As noted in > an earlier message on this thread [0], using MaxBackends in a call to > RequestAddinShmemSpace() in _PG_init() may not reliably cause > problems, too.
Yes, I think MaxBackends is a particularly severe case. I've seen this problem with that GUC multiple times, and never with any other one. > > It seems overkill to remove "extern" from MaxBackends and replace > > MaxBackends with GetMaxBackends() in the existing PostgreSQL codes. I'm not > > sure how much it's actually worth doing that. Instead, isn't it enough to > > just add the comment like "Use GetMaxBackends() if you want to treat the > > lookup for uninitialized MaxBackends as an error" in the definition of > > MaxBackends? > > While that approach would provide a way to safely retrieve the value, > I think it would do little to prevent the issue in practice. If the > size of the patch is a concern, we could also convert MaxBackends into > a macro for calling GetMaxBackends(). This could also be a nice way > to avoid breaking extensions that are using it correctly while > triggering ERRORs for extensions that are using it incorrectly. I've > attached a new version of the patch that does it this way. That's too magical for my taste. -- Robert Haas EDB: http://www.enterprisedb.com
