Re: add function for creating/attaching hash table in DSM registry - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id CAA5RZ0tWrJ8SwBbqtix-qcUm30_sr2ybhDanF8iOjOX8oyYU2Q@mail.gmail.com
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Nathan Bossart <nathandbossart@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: "Daniel Verite"
Date:
Subject: Re: CREATE DATABASE command for non-libc providers