MIME-Version: 1.0
References: 
 <CAA5RZ0tKfCVqFnMZtavM42H63ha2Haf_C4mbJNWqkaW30cPW1w@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0tKfCVqFnMZtavM42H63ha2Haf_C4mbJNWqkaW30cPW1w@mail.gmail.com>
From: jie wang <jugierwang@gmail.com>
Date: Tue, 7 Apr 2026 11:59:14 +0800
Message-ID: 
 <CAJnZyeCTvcAQshs8BHSDTAZ6JJgo619sFgWmdKHKf_UawgdeYA@mail.gmail.com>
Subject: Re: Return DSA area for hash table from GetNamedDSHash()
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000005c6337064ed6cf8e"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJnZyeCTvcAQshs8BHSDTAZ6JJgo619sFgWmdKHKf_UawgdeYA%40mail.gmail.com>
Precedence: bulk

--0000000000005c6337064ed6cf8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sami Imseih <samimseih@gmail.com> =E4=BA=8E2026=E5=B9=B44=E6=9C=887=E6=97=
=A5=E5=91=A8=E4=BA=8C 06:56=E5=86=99=E9=81=93=EF=BC=9A

> 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 lim=
it
> 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 fo=
r
> pg_dsm_registry_allocations to also show the max_size
>
> postgres=3D# 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 !=3D NULL);

Best regards,
--
wang jie

--0000000000005c6337064ed6cf8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Sami Imseih &lt=
;<a href=3D"mailto:samimseih@gmail.com">samimseih@gmail.com</a>&gt; =E4=BA=
=8E2026=E5=B9=B44=E6=9C=887=E6=97=A5=E5=91=A8=E4=BA=8C 06:56=E5=86=99=E9=81=
=93=EF=BC=9A<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,=
<br>
<br>
While working on extending tests for dshash.c [1], I realized that a<br>
user that creates a hash table with GetNamedDSHash() has no way<br>
to cap the size of the dsa area underpinning the table by using<br>
dsa_set_size_limit(). This is because the dsa_area created using<br>
this API is not exposed to the user.<br>
<br>
This is a gap for users of the GetNamedDSHash() API,<br>
because it&#39;s very likely that the callers don&#39;t want runaway growth=
 of<br>
these hash tables.<br>
<br>
Attached is a new API, dshash_get_dsa_area() that takes in a dshash_table<b=
r>
and returns the area. The caller can then use dsa_set_size_limit() to limit=
<br>
the size.<br>
<br>
We could change the GetNamedDSHash() API to take in a size, but that<br>
will not be ideal since a caller may want to change the size dynamically af=
ter<br>
the hash table is created.<br>
<br>
I don&#39;t have a patch for this yet, but I also think it will make sense =
for<br>
pg_dsm_registry_allocations to also show the max_size<br>
<br>
postgres=3D# select * from pg_dsm_registry_allocations;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 type=C2=A0 =C2=A0|=C2=A0 size<br>
------------------------+---------+---------<br>
=C2=A0test_dsm_registry_dsa=C2=A0 | area=C2=A0 =C2=A0 | 1048576<br>
=C2=A0test_dsm_registry_hash | hash=C2=A0 =C2=A0 | 1048576<br>
=C2=A0test_dsm_registry_dsm=C2=A0 | segment |=C2=A0 =C2=A0 =C2=A0 20<br>
(3 rows)<br>
<br>
Thoughts?<br>
<br>
<br>
[1] [<a href=3D"https://www.postgresql.org/message-id/acXCJODjsCytdpwT%40pa=
quier.xyz" rel=3D"noreferrer" target=3D"_blank">https://www.postgresql.org/=
message-id/acXCJODjsCytdpwT%40paquier.xyz</a>]<br>
<br>
--<br>
Sami Imseih<br>
Amazon Web Services (AWS)<br></blockquote><div><br></div><div><br></div>Hi,=
<br><br>I think an assert check could be added in this patch for better saf=
ety.<br>=C2=A0Assert(hash_table !=3D NULL);<br><br>Best regards,<br>--<br><=
div>wang jie=C2=A0</div></div></div>

--0000000000005c6337064ed6cf8e--