Move dynamically-allocated LWLock tranche names to shared memory.
authorNathan Bossart <nathan@postgresql.org>
Wed, 3 Sep 2025 18:57:48 +0000 (13:57 -0500)
committerNathan Bossart <nathan@postgresql.org>
Wed, 3 Sep 2025 18:57:48 +0000 (13:57 -0500)
commit38b602b0289fe1dbaf31d5737fba2d42a1e90371
treed4d49ed39690c297041e29446c7ceb88446b2a87
parent7b0fb9f5c68e7c7161a88b442f41b5345cd6cdd0
Move dynamically-allocated LWLock tranche names to shared memory.

There are two ways for shared libraries to allocate their own
LWLock tranches.  One way is to call RequestNamedLWLockTranche() in
a shmem_request_hook, which requires the library to be loaded via
shared_preload_libraries.  The other way is to call
LWLockNewTrancheId(), which is not subject to the same
restrictions.  However, LWLockNewTrancheId() does require each
backend to store the tranche's name in backend-local memory via
LWLockRegisterTranche().  This API is a little cumbersome and leads
to things like unhelpful pg_stat_activity.wait_event values in
backends that haven't loaded the library.

This commit moves these LWLock tranche names to shared memory, thus
eliminating the need for each backend to call
LWLockRegisterTranche().  Instead, the tranche name must be
provided to LWLockNewTrancheId(), which immediately makes the name
available to all backends.  Since the tranche name array is
append-only, lookups can ordinarily avoid locking as long as their
local copy of the LWLock counter is greater than the requested
tranche ID.

One downside of this approach is that we now have a hard limit on
both the length of tranche names (NAMEDATALEN-1 bytes) and the
number of dynamically-allocated tranches (256).  Besides a limit of
NAMEDATALEN-1 bytes for tranche names registered via
RequestNamedLWLockTranche(), no such limits previously existed.  We
could avoid these new limits by using dynamic shared memory, but
the complexity involved didn't seem worth it.  We briefly
considered making the tranche limit user-configurable but
ultimately decided against that, too.  Since there is still a lot
of time left in the v19 development cycle, it's possible we will
revisit this choice.

Author: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CAA5RZ0vvED3naph8My8Szv6DL4AxOVK3eTPS0qXsaKi%3DbVdW2A%40mail.gmail.com
contrib/pg_prewarm/autoprewarm.c
doc/src/sgml/xfunc.sgml
src/backend/postmaster/launch_backend.c
src/backend/storage/ipc/dsm_registry.c
src/backend/storage/lmgr/lwlock.c
src/include/storage/lwlock.h
src/test/modules/test_dsa/test_dsa.c
src/test/modules/test_dsm_registry/test_dsm_registry.c
src/test/modules/test_radixtree/test_radixtree.c
src/test/modules/test_slru/test_slru.c
src/test/modules/test_tidstore/test_tidstore.c