From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve LWLock tranche name visibility across backends |
Date: | 2025-09-04 13:51:21 |
Message-ID: | aLmZWcqRiPY7QRi-@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 04, 2025 at 03:29:52PM +0530, Rahila Syed wrote:
> Since updates to LocalLWLockCounter and LWLockTrancheNames are performed
> while holding the lock, but reading LocalLWLockCounter and then
> LWLockTrancheNames in GetLWTrancheName can occur without acquiring the
> same lock in case trancheID < LocalLWLockCounter, There is a small window
> between updating LocalLWLockCounter and adding the name to
> LWLockTrancheNames. During this window, if GetLWTrancheNames is called,
> it might attempt to access a name in LWLockTrancheNames that hasn't been
> added yet.
We hold the lock when reading/writing the shared-memory LWLockCounter.
There's no need to take a lock when reading the backend-local
LocalLWLockCounter, as it can't be modified by any other process.
Additionally, when adding a new tranche name, we hold the lock the entire
time while we bump the shared-memory counter and copy the name, so there's
no chance another backend will see the counter update but not the name or
attempt to use the same LWLockTrancheNames slot.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-09-04 13:55:16 | Re: Solaris compiler status |
Previous Message | Fabrice Chapuis | 2025-09-04 13:26:59 | issue with synchronized_standby_slots |