From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathan(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Move named LWLock tranche requests to shared memory. |
Date: | 2025-09-17 04:47:19 |
Message-ID: | aMo9V5A7S30mwCcR@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-09-17 14:34:24 | Re: pgsql: Move named LWLock tranche requests to shared memory. |
Previous Message | Nathan Bossart | 2025-09-17 04:10:34 | Re: pgsql: Move named LWLock tranche requests to shared memory. |