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  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: typos
Следующее
От: David Rowley
Дата:
Сообщение: Re: First draft of the PG 15 release notes