Re: dshash_find_or_insert vs. OOM

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Robert Haas <robertmhaas(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-19 00:08:26
Message-ID: 8170A3AF-C066-4963-B7B4-A3E7CCBCC3FE@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mar 19, 2026, at 01:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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
> <v2-0001-dshash-Make-it-possible-to-suppress-out-of-memory.patch>

Thanks for updating the patch. V2 LGTM.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-03-19 00:40:55 Re: Feature freeze timezone change request
Previous Message Lukas Fittl 2026-03-18 23:36:03 Re: Stack-based tracking of per-node WAL/buffer usage