Re: Improve LWLock tranche name visibility across backends

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

In response to

Responses

Browse pgsql-hackers by date

  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