Re: dshash_find_or_insert vs. OOM - Mailing list pgsql-hackers

From Robert Haas
Subject Re: dshash_find_or_insert vs. OOM
Date
Msg-id CA+TgmoYc1PG27ySdjX+fv85-iXA-qNj-AybxQAE7kseKv+qdLQ@mail.gmail.com
Whole thread
In response to Re: dshash_find_or_insert vs. OOM  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: dshash_find_or_insert vs. OOM
Re: dshash_find_or_insert vs. OOM
List pgsql-hackers
On Tue, Mar 17, 2026 at 9:34 PM Chao Li <li.evan.chao@gmail.com> wrote:
> When OOM happens, Assert((flags & DSHASH_INSERT_NO_OOM) != 0); makes sense. But for resize(), the assert is inside
resize(),while for insert_into_bucket(), the assert is in the caller. That feels a bit inconsistent to me, and I think
ithurts readability a little. A reader might wonder why there is no corresponding assert after resize() unless they go
readthe function body. 

Adjusted.

> Making this a nested block does have the benefit of keeping dsa_flags close to where it is used. But from my
impression,this style is still fairly uncommon in the codebase. I worry it may implicitly signal to other hackers that
thisis an acceptable pattern. So unless we intentionally want to encourage that style, I would lean toward avoiding it
here.

Yeah, that was dumb. Fixed.

Thanks for the review; here's v2.

--
Robert Haas
EDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: "Matheus Alcantara"
Date:
Subject: Re: Avoid resource leak (contrib/postgres_fdw/connection.c)
Next
From: Masahiko Sawada
Date:
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions