| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Return DSA area for hash table from GetNamedDSHash() |
| Date: | 2026-04-06 22:56:21 |
| Message-ID: | CAA5RZ0tKfCVqFnMZtavM42H63ha2Haf_C4mbJNWqkaW30cPW1w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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)
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Add-function-to-return-DSA-area-for-a-dshash-tabl.patch | application/octet-stream | 1.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-04-06 23:09:33 | Re: SLOPE - Planner optimizations on monotonic expressions. |
| Previous Message | Jim Jones | 2026-04-06 22:52:20 | Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables |