Re: Improve LWLock tranche name visibility across backends

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(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-19 20:59:39
Message-ID: aKTlu7mHhx4owx6r@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 19, 2025 at 03:52:33PM -0500, Sami Imseih wrote:
> If we limit the tranche name to NAMEDATALEN and also limit the
> number of tranches an extension can register, we can put this
> all in static shared memory (We would still need to have a backend local
> cache to allow lookups to avoid going to shared memory).

I bet we could avoid the local cache by keeping a backend-local copy of
LWLockCounter that gets updated as needed.

> However, I am not sure what the limit would be for the number of tranches,
> and if we do impose something, will it break anything that is out there?

I can think of contrived scenarios where these limits would present
problems, but I'm not aware of anything that folks are actually doing that
would be affected. In general, the examples I've seen involve allocating a
small number of tranches for an extension, so my assumption is that the
most likely cause of breakage would be someone installing many, many
extensions.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-08-19 21:01:49 Re: Remove traces of long in dynahash.c
Previous Message Sami Imseih 2025-08-19 20:52:33 Re: Improve LWLock tranche name visibility across backends