On 1/7/22, 8:54 AM, "Fujii Masao" <masao.fujii@oss.nttdata.com> wrote:
> The patch handles only MaxBackends. But isn't there other variable having the same issue?
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.
> 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.
Nathan
[0] https://postgr.es/m/8499D41B-628A-4CE0-9139-00D718F9D06B%40amazon.com