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 Yj1OOR/oQOrEt7OI@paquier.xyz
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Fri, Mar 25, 2022 at 11:11:46AM +0800, Julien Rouhaud wrote:
> As an example, here's a POC for a new shmem_request_hook hook after _PG_init().
> With it I could easily fix pg_wait_sampling shmem allocation (and checked that
> it's indeed requesting the correct size).

Are you sure that the end of a release cycle is the good moment to
begin designing new hooks?  Anything added is something we are going
to need supporting moving forward.  My brain is telling me that we
ought to revisit the business with GetMaxBackends() properly instead,
and perhaps revert that.

This solution makes me uneasy from the start (already stated
upthread), because it is not a solution to the original problem, just
a safeguard that handles one small-ish portion of the whole parameter
calculation cycle.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: CREATE INDEX CONCURRENTLY on partitioned index
Next
From: Greg Stark
Date:
Subject: Re: Add LZ4 compression in pg_dump