| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> | 
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> | 
| Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: add function for creating/attaching hash table in DSM registry | 
| Date: | 2025-06-10 16:21:37 | 
| Message-ID: | aEhbkQIkICHGRqWy@nathan | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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 mechanism of registering a DSA or a HASH.
>> I think it will be odd to append "_dsh", but we should at minimum add
>> a comment in the GetNamedDSMHash explaining this.
> 
> This should be addressed in v3.
> 
> 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?
Unrelated, but it'd probably be a good idea to make sure the segment is
initialized instead of assuming it'll be zeroed out (and further assuming
that DSHASH_HANDLE_INVALID is 0)...
-- 
nathan
| Attachment | Content-Type | Size | 
|---|---|---|
| v4-0001-simplify-creating-hash-table-in-dsm-registry.patch | text/plain | 10.8 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2025-06-10 16:30:33 | Re: Cleanup gcc trick with varattrib_1b_e in VARATT_EXTERNAL_GET_POINTER() | 
| Previous Message | Junwang Zhao | 2025-06-10 16:07:35 | Use RELATION_IS_OTHER_TEMP where possible |