Re: pgsql: Move named LWLock tranche requests to shared memory. - Mailing list pgsql-committers

From Michael Paquier
Subject Re: pgsql: Move named LWLock tranche requests to shared memory.
Date
Msg-id aMo9V5A7S30mwCcR@paquier.xyz
Whole thread Raw
In response to Re: pgsql: Move named LWLock tranche requests to shared memory.  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pgsql: Move named LWLock tranche requests to shared memory.
List pgsql-committers
On Tue, Sep 16, 2025 at 11:10:34PM -0500, Nathan Bossart wrote:
> I was able to simplify the patch.

+   if (LocalNamedLWLockTrancheRequestArray)
+       NamedLWLockTrancheRequestArray = LocalNamedLWLockTrancheRequestArray;

It's not a common practice in the code to rely on a shmem state that
should be already set in a routine reporting the size of how much
should be allocated, but that seems OK to live with that here with a
local pointer used un !IsUnderPostmaster.

Perhaps LocalNamedLWLockTrancheRequestArray should be initialized to
NULL when declared, and I'd rather document the reasons behind what
this patch is doing in LWLockShmemSize() and when the state is
initialized in CreateLWLocks(), than have the reader assume why the
local pointer is needed (aka reinitialized with restart_after_crash).

013, 022 and 041 look happy with this solution, with or without
EXEC_BACKEND.

Note: I forgot for a second if shared_preload_libraries was reloaded
when the postmaster reinitializes a cluster, and the answer is that
we only go into process_shared_preload_libraries() once at startup..
I was wondering for a second about a potential case where s_p_l is
updated with more lwlocks added in-between, where a reinitialization
would mess up things.
--
Michael

Attachment

pgsql-committers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: pgsql: Move named LWLock tranche requests to shared memory.
Next
From: Nathan Bossart
Date:
Subject: Re: pgsql: Move named LWLock tranche requests to shared memory.