| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | jugierwang(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Return DSA area for hash table from GetNamedDSHash() |
| Date: | 2026-08-03 11:09:32 |
| Message-ID: | anB27FIrmUyaLJqk@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 09, 2026 at 04:11:48PM -0500, Sami Imseih wrote:
> hm, having GetNamedDSA return dsa_area for direct use while requiring
> a special wrapper for the dshash case creates an inconsistent API in
> dsm_registry.h. dshash_get_dsa_area() means either way the dsa_area is
> obtained, dsa_set_size_limit() can be used to set the size.
(Took me some time to get back to this thread..)
Another argument that I could have is somebody registering the dshash
in the registry, then allocate more objects in the same area retrieved
by the new routine. Perhaps my imagination is too fancy, but perhaps
some will find this option useful. I also got the parallel with the
existing get_handle().
Anyway, applied under the DSM registry argument, mainly.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-08-03 11:16:57 | Re: Allow a condition string in an injection point |
| Previous Message | Nazir Bilal Yavuz | 2026-08-03 11:07:48 | Re: Add a pg_wal_preallocate() SQL function to eagerly create future WAL segments |