> 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
On Tue, Jun 10, 2025 at 02:05:16PM -0500, Sami Imseih wrote:
> There is also that dynamic tranche named are stored in local backend
> look-up table, so if you have some backends that attached some dynamic
> hash table
> and others that did not, only the ones that registered would be able to
> resol
There is also that dynamic tranche named are stored in local backend
look-up table, so if you have some backends that attached some dynamic
hash table
and others that did not, only the ones that registered would be able to
resolve the tranche id to its name.
This is the case which I encountered ye
> I'm not quite following your uneasiness with the tranche names. For the
> dshash table, we'll need a tranche for the DSA and one for the hash table,
> so presumably any wait events for those locks should be named accordingly,
> right?
I may be alone in this opinion, but I prefer the suffixless
On Tue, Jun 10, 2025 at 07:47:02PM +0300, Florents Tselai wrote:
> Love this new API.
Thanks!
> a minor typo here
> + * current backend. This function gurantees that only one backend
Fixed.
> Since you made the first step towards decoupling DSMR_NAME_LEN from
> NAMEDATALEN;
> is it worth con
> On 10 Jun 2025, at 7:21 PM, Nathan Bossart wrote:
>
> On Tue, Jun 10, 2025 at 10:38:29AM -0500, Nathan Bossart wrote:
>> On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote:
>>> Going back to the original point, DSMRegistryHash and DSMRegistryHash
>>> are built-in, and those names are
On Tue, Jun 10, 2025 at 10:38:29AM -0500, Nathan Bossart wrote:
> On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote:
>> Going back to the original point, DSMRegistryHash and DSMRegistryHash
>> are built-in, and those names are well-defined and actually refer to
>> waits related to the mec
On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote:
> Going back to the original point, DSMRegistryHash and DSMRegistryHash
> are built-in, and those names are well-defined and actually refer to
> waits related to the mechanism of registering a DSA or a HASH.
> I think it will be odd to ap
> It is not expected behavior IMO, and I still need to debug this a bit more,
> but it may be something outside the scope of this patch that the patch just
> surfaced.
It seems I got it backward. If the tranch is registered, then the wait event
name is the one of the tranche, in that case we will
> On Mon, Jun 09, 2025 at 03:10:30PM -0500, Sami Imseih wrote:
> > One thing I noticed, and I´m not too fond of, is that the wait_event name
> > shows
> > up with the _dsh suffix:
> >
> > ```
> > postgres=# select query, wait_event, wait_event_type from pg_stat_activity ;
> > query | wait_event
>
On Mon, Jun 09, 2025 at 03:10:30PM -0500, Sami Imseih wrote:
> One thing I noticed, and I´m not too fond of, is that the wait_event name
> shows
> up with the _dsh suffix:
>
> ```
> postgres=# select query, wait_event, wait_event_type from pg_stat_activity ;
> query | wait_event
> | wait_event_ty
Thanks, I tested v2 a bit more and did a quick hack of pg_stat_statements just
to get a feel for what it would take to use the new API to move the hash table
from static to dynamic.
One thing I noticed, and I’m not too fond of, is that the wait_event name shows
up with the _dsh suffix:
```
postgr
On Thu, Jun 05, 2025 at 01:38:25PM -0500, Sami Imseih wrote:
> I have a few early comments, but I plan on trying this out next.
Thanks for reviewing.
>> > +typedef struct NamedDSMHashState
>> > +{
>> > + dsa_handle dsah;
>> > + dshash_table_handle dshh;
>> > + int
Thanks for this patch! I have implemented this pattern several times,
so this is really helpful.
I have a few early comments, but I plan on trying this out next.
1/
> > +typedef struct NamedDSMHashState
> > +{
> > + dsa_handle dsah;
> > + dshash_table_handle dshh;
> > + int
Nathan Bossart writes:
> +typedef struct NamedDSMHashState
> +{
> + dsa_handle dsah;
> + dshash_table_handle dshh;
> + int dsa_tranche;
> + chardsa_tranche_name[68]; /* name + "_dsa" */
> + int dsh_tranche;
> + cha
Libraries commonly use shared memory to store hash tables. While it's
possible to set up a dshash table using the DSM registry today, doing so is
complicated; you need to set up two LWLock tranches, a DSA, and finally the
dshash table. The attached patch adds a new function called
GetNamedDSMHash
16 matches
Mail list logo
