Re: make MaxBackends available in _PG_init
| От | Nathan Bossart |
|---|---|
| Тема | Re: make MaxBackends available in _PG_init |
| Дата | |
| Msg-id | 20220419154658.GA2487941@nathanxps13 обсуждение исходный текст |
| Ответ на | Re: make MaxBackends available in _PG_init (Julien Rouhaud <rjuju123@gmail.com>) |
| Ответы |
Re: make MaxBackends available in _PG_init
Re: make MaxBackends available in _PG_init |
| Список | pgsql-hackers |
On Tue, Apr 19, 2022 at 05:49:13PM +0800, Julien Rouhaud wrote: > On Mon, Apr 18, 2022 at 08:17:04PM -0400, Tom Lane wrote: >> Nathan Bossart <nathandbossart@gmail.com> writes: >> > I'm looking for a clean way to ERROR if someone attempts to call >> > RequestAddinShmemSpace() or RequestNamedLWLockTranche() outside of the >> > hook. Currently, we are using static variables in ipci.c and lwlock.c to >> > silently ignore invalid requests. I could add a new 'extern bool' called >> > 'process_shmem_requests_in_progress', but extensions could easily hack >> > around that to allow requests in _PG_init(). Maybe I am overthinking all >> > this and that is good enough. >> >> If they do that and it breaks something, that's their fault not ours. >> (It's not like there's not $BIGNUM ways for a C-language module to >> break the backend, anyway.) > > Agreed. Similarly the process_shared_preload_libraries_in_progress flag could > be modified by extension, and that wouldn't be any better. > >> BTW, I'd make such errors FATAL, as it's unlikely that we can recover >> cleanly from an error during initialization of a loadable module. >> The module's likely to be only partially initialized/hooked in. > > While at it, should we make process_shmem_requests_in_progress true when the > new hook is called? The hook should only be called when that's the case, and > extension authors may feel like asserting it. Okay, I did it this way in v5. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: