Re: make MaxBackends available in _PG_init
От | Michael Paquier |
---|---|
Тема | Re: make MaxBackends available in _PG_init |
Дата | |
Msg-id | Ynsc9bRL1caUSBSE@paquier.xyz обсуждение исходный текст |
Ответ на | Re: make MaxBackends available in _PG_init (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: make MaxBackends available in _PG_init
|
Список | pgsql-hackers |
On Tue, May 10, 2022 at 08:56:28AM -0700, Nathan Bossart wrote: > On Tue, May 10, 2022 at 05:55:12PM +0900, Michael Paquier wrote: >> I agree that removing support for the unloading part would be nice to >> clean up now on HEAD. Note that 0002 is missing the removal of one >> reference to _PG_fini in xfunc.sgml (<primary> markup). > > Oops, sorry about that. 0002 looks pretty good from here. If it were me, I would apply 0002 first to avoid the extra tweak in pg_stat_statements with _PG_fini in 0001. Regarding 0001, I have spotted an extra issue in the documentation. xfunc.sgml has a section called "Shared Memory and LWLocks" about the use of RequestNamedLWLockTranche() and RequestAddinShmemSpace() called from _PG_init(), which would now be wrong as we'd need the hook. IMO, the docs should mention the registration of the hook in _PG_init(), the APIs involved, and should mention to look at pg_stat_statements.c for a code sample (we tend to avoid the addition of sample code in the docs lately as we habe no way to check their compilation automatically). Robert, are you planning to look at what's proposed and push these? FWIW, I am familiar enough with the problems at hand to do this in time for beta1 (aka by tomorrow to give it room in the buildfarm), but I don't want to step on your feet, either. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: