On Fri, Jan 7, 2022 at 1:09 PM Bossart, Nathan <bossartn@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
PostgreSQLcodes. I'm not sure how much it's actually worth doing that. Instead, isn't it enough to just add the
commentlike "Use GetMaxBackends() if you want to treat the lookup for uninitialized MaxBackends as an error" in the
definitionof 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