Horton

Re: add function for creating/attaching hash table in DSM registry

Sami Imseih <samimseih@gmail.com>

View thread View on postgr.es
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Florents Tselai <florents.tselai@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2025-06-10T21:28:15Z
Lists: pgsql-hackers 
> So, if we were adding named LWLocks today, I suspect we might do it
> differently.  The first thing that comes to mind is that we could store a
> shared LWLockTrancheNames table.

+1

> and stop requiring each backend to register them individually.

which will prevent odd behavior when a backend does not register
a tranche.

> In short, LWLockNewTrancheId() would gain a new name argument, and
> LWLockRegisterTranche() would disappear.

That looks sane to me. The only reason LWLockNewTrancheId and
LWLockRegisterTranche are currently separate is because each
backend has to register, so having separate routines is necessary.


> We would probably need to be
> smart to avoid contention on the name table, but that feels avoidable to

Most of the time, we would be reading and not updating the table, so
contention may not be a big problem.

--
Sami

Commits

  1. Fix cross-version upgrade test breakage from commit fe07100e82.

  2. Add GetNamedDSA() and GetNamedDSHash().

  3. Remove dynamic_shared_memory_type=none

  4. Introduce dynamic shared memory areas.

  5. Relax the requirement that all lwlocks be stored in a single array.