Re: dshash_find_or_insert vs. OOM
| От | Chao Li |
|---|---|
| Тема | Re: dshash_find_or_insert vs. OOM |
| Дата | |
| Msg-id | 8170A3AF-C066-4963-B7B4-A3E7CCBCC3FE@gmail.com обсуждение исходный текст |
| Ответ на | Re: dshash_find_or_insert vs. OOM (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: dshash_find_or_insert vs. OOM
|
| Список | pgsql-hackers |
> On Mar 19, 2026, at 01:46, Robert Haas <robertmhaas@gmail.com> wrote: > > 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 > <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/
В списке pgsql-hackers по дате отправления: