From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve LWLock tranche name visibility across backends |
Date: | 2025-08-25 21:37:21 |
Message-ID: | CAA5RZ0vh7jrGDwJgkKtw-LR5fBH-tRNpGJnPivdKedtqJ7HGCQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Fri, Aug 22, 2025 at 03:01:53PM -0500, Sami Imseih wrote:
> > I kept the local array to serve consecutive reads and to avoid having to
> > take a shared lock on shared memory every time GetLWTrancheName is
> > called. A new LWLock to protect this array is required.
>
> I'm not seeing why we need this cache anymore. This is an append-only
> list, so we could instead keep a backend-local copy of LWLockCounter that
> gets updated as needed. As long as the ID is less than our backend-local
> counter, we can go straight to the shared array. If it is greater, we'll
> have to first update our counter, which should be rare and inexpensive.
When we lookup from shared array only, we need to take a shared lock
every lookup. Acquiring that lock is what I am trying to avoid. You
are saying it's not worth optimizing that part, correct?
--
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-08-25 21:41:22 | Re: GetNamedLWLockTranche crashes on Windows in normal backend |
Previous Message | Sami Imseih | 2025-08-25 21:28:09 | Re: GetNamedLWLockTranche crashes on Windows in normal backend |