Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id Ynsc9bRL1caUSBSE@paquier.xyz
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: make MaxBackends available in _PG_init
List 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

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: typos
Next
From: David Rowley
Date:
Subject: Re: First draft of the PG 15 release notes