Re: Return DSA area for hash table from GetNamedDSHash()

From: jie wang <jugierwang(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Return DSA area for hash table from GetNamedDSHash()
Date: 2026-04-07 03:59:14
Message-ID: CAJnZyeCTvcAQshs8BHSDTAZ6JJgo619sFgWmdKHKf_UawgdeYA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sami Imseih <samimseih(at)gmail(dot)com> 于2026年4月7日周二 06:56写道:

> Hi,
>
> While working on extending tests for dshash.c [1], I realized that a
> user that creates a hash table with GetNamedDSHash() has no way
> to cap the size of the dsa area underpinning the table by using
> dsa_set_size_limit(). This is because the dsa_area created using
> this API is not exposed to the user.
>
> This is a gap for users of the GetNamedDSHash() API,
> because it's very likely that the callers don't want runaway growth of
> these hash tables.
>
> Attached is a new API, dshash_get_dsa_area() that takes in a dshash_table
> and returns the area. The caller can then use dsa_set_size_limit() to limit
> the size.
>
> We could change the GetNamedDSHash() API to take in a size, but that
> will not be ideal since a caller may want to change the size dynamically
> after
> the hash table is created.
>
> I don't have a patch for this yet, but I also think it will make sense for
> pg_dsm_registry_allocations to also show the max_size
>
> postgres=# select * from pg_dsm_registry_allocations;
> name | type | size
> ------------------------+---------+---------
> test_dsm_registry_dsa | area | 1048576
> test_dsm_registry_hash | hash | 1048576
> test_dsm_registry_dsm | segment | 20
> (3 rows)
>
> Thoughts?
>
>
> [1] [https://www.postgresql.org/message-id/acXCJODjsCytdpwT%40paquier.xyz]
>
> --
> Sami Imseih
> Amazon Web Services (AWS)
>

Hi,

I think an assert check could be added in this patch for better safety.
Assert(hash_table != NULL);

Best regards,
--
wang jie

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-04-07 04:02:47 Re: Implement waiting for wal lsn replay: reloaded
Previous Message Chao Li 2026-04-07 03:58:08 Re: Add missing stats_reset column to pg_stat_database_conflicts view