Hi,
Thank you for the updated patch.
Using a DSA from the registry is cumbersome. You essentially need
> another batch of shared memory to keep track of the pointers and do
locking, so it might not be tremendously useful on its own
>
Isn't this true while using dshash from the registry as wel
On Fri, Jun 13, 2025 at 08:31:22PM +0530, Rahila Syed wrote:
> I am considering whether it would be better to avoid creating another DSM
> segment to track the DSA handle. Would it make more sense to track the
> DSAs in a separate dshash registry similar to DSM segments?
I don't know if it's bette
Hi,
> * Using a DSA from the registry is cumbersome. You essentially need
> another batch of shared memory to keep track of the pointers and do
> locking, so it might not be tremendously useful on its own. AFAICT the
> easiest thing to do is to store the DSA pointers in a dshash table, wh
> Okay, I've done this in the attached patch.
Thanks! v7 LGTM.
--
Sami
On Wed, Jun 11, 2025 at 05:15:36PM -0500, Sami Imseih wrote:
> I tested v6 and I think GetNamedDSA is a good addition. I did
> not find any issues with the code. However, I am still convinced
> that GetNamedDSMHash should not append " Hash" to the tranche
> name of the dshash [0]. I am ok with "
I tested v6 and I think GetNamedDSA is a good addition. I did
not find any issues with the code. However, I am still convinced
that GetNamedDSMHash should not append " Hash" to the tranche
name of the dshash [0]. I am ok with " DSA" because the DSA tranche
is created implicitly by the API.
Also,
Here is a new patch with GetNamedDSA() added. A couple notes:
* I originally wanted to use GetNamedDSA() within GetNamedDSMHash(), but
that would probably lead to two registry entries per dshash table, and it
didn't really save all that much code, anyway. So, I didn't do that.
* Using a DSA
> On 11 Jun 2025, at 5:23 PM, Nathan Bossart wrote:
>
> On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote:
>>> On 11 Jun 2025, at 4:57 PM, Nathan Bossart wrote:
>>> I considered adding another function that would create/attach a DSA in the
>>> DSM registry, since that's already
On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote:
>> On 11 Jun 2025, at 4:57 PM, Nathan Bossart wrote:
>> I considered adding another function that would create/attach a DSA in the
>> DSM registry, since that's already an intermediate step of dshash creation.
>> We could then use th
> On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote:
> >> How can one dsa_allocate in the same area as the returned dshash_table ?
> >> in other words: shouldn't the state->dsa_handle be returned somehow ?
> >
> > +1. FWIW, Having used the DSA apis in my code, I think having the
> registr
> On 11 Jun 2025, at 4:57 PM, Nathan Bossart wrote:
>
> On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote:
>>> How can one dsa_allocate in the same area as the returned dshash_table ?
>>> in other words: shouldn't the state->dsa_handle be returned somehow ?
>>
>> +1. FWIW, Having us
On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote:
>> How can one dsa_allocate in the same area as the returned dshash_table ?
>> in other words: shouldn't the state->dsa_handle be returned somehow ?
>
> +1. FWIW, Having used the DSA apis in my code, I think having the registry
> return
>
Hi,
Thank you for proposing this enhancement to the DSM registry. It will make
it easier
to use dshash functionality.
> While trying to port some existing DSMR code, I came across this
> limitation:
>
> How can one dsa_allocate in the same area as the returned dshash_table ?
> in other words: sh
> On 10 Jun 2025, at 8:25 PM, Nathan Bossart wrote:
>
> 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
> 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
29 matches
Mail list logo
