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: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve LWLock tranche name visibility across backends
Date: 2025-07-31 21:24:38
Message-ID: aIvfFqqIPJjagSgD@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've attached a rebased version of the patch.

On Mon, Jul 21, 2025 at 11:26:44PM -0500, Sami Imseih wrote:
> Unlike the local list of tranche names, appending to and searching the
> shared memory list requires an LWLock; in exclusive mode to append, and
> shared mode to search.

The thing that stood out the most to me is how much more expensive looking
up the lock name is. At the risk of suggesting even more complexity, I'm
wondering if we should add some sort of per-backend cache to avoid the need
for locking and dsa_get_address() calls every time you need to look up a
lock name.

Also, I suspect that there might be some concerns about the API changes.
While it should be a very easy fix, that seems likely to break a lot of
extensions. I don't know if it's possible to make this stuff backward
compatible, and I also don't know if we really want to, as that'll both
introduce more complexity and keep folks using the old API. (That being
said, I just looked on GitHub and Debian Code Search and was surprised at
how few uses of LWLockNewTrancheId() and LWLockRegisterTranche() there
are...)

--
nathan

Attachment Content-Type Size
v3-0001-Store-LWLock-tranche-names-registered-after-postm.patch text/plain 26.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2025-07-31 21:48:08 Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Previous Message Greg Sabino Mullane 2025-07-31 20:42:26 Re: Enable data checksums by default