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

From Nathan Bossart
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id 20220419001220.GA2389330@nathanxps13
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make MaxBackends available in _PG_init
List pgsql-hackers
On Mon, Apr 18, 2022 at 07:33:54PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> I noticed that requests for more LWLocks follow a similar pattern as
>> regular shared memory requests, and I figured that we would want to do
>> something similar for those, but I wasn't sure exactly how to proceed.  I
>> saw two options: 1) use shmem_request_hook for both regular requests and
>> LWLock requests or 2) introduce an lwlock_request_hook.  My instinct was
>> that option 1 was preferable,
> 
> Yeah, I agree, which says that maybe the hook name needs to be something
> else (not that I have a good proposal).
> 
>> but AFAICT this requires introducing a new
>> external variable for inspecting whether the request is made at a valid
>> time.
> 
> Uh, why?  It'd be the core code's responsibility to place the hook
> call at a point where you could do both.

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.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508