Re: dshash_find_or_insert vs. OOM

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: dshash_find_or_insert vs. OOM
Date: 2026-03-18 17:46:14
Message-ID: CA+TgmoYc1PG27ySdjX+fv85-iXA-qNj-AybxQAE7kseKv+qdLQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 17, 2026 at 9:34 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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 it hurts readability a little. A reader might wonder why there is no corresponding assert after resize() unless they go read the 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 this is 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 Content-Type Size
v2-0001-dshash-Make-it-possible-to-suppress-out-of-memory.patch application/octet-stream 9.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-03-18 17:52:30 Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Previous Message Matheus Alcantara 2026-03-18 17:42:35 Re: Avoid resource leak (contrib/postgres_fdw/connection.c)