Re: make MaxBackends available in _PG_init
От | Bossart, Nathan |
---|---|
Тема | Re: make MaxBackends available in _PG_init |
Дата | |
Msg-id | 7239E4F9-A46D-4A61-9200-8B1366D03ADB@amazon.com обсуждение исходный текст |
Ответ на | Re: make MaxBackends available in _PG_init (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: make MaxBackends available in _PG_init
Re: make MaxBackends available in _PG_init |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: