From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options |
Date: | 2025-08-15 03:22:18 |
Message-ID: | OSCPR01MB1496650D03FA0293AB9C21416F534A@OSCPR01MB14966.jpnprd01.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Tom,
Thanks for the analysis.
> Based on this, I think we should remove the HASH_DEBUG support.
> It's been broken for six of the last nine years and only one
> person ever noticed. Moreover, if you were trying to find a
> problem in dynahash, you'd probably want different debug logging
> than what's here.
I didn't realize that it has been broken for a long time. Agreed to remove
the HASH_DEBUG option.
> There might be a case for removing HASH_STATISTICS too, but
> it seems weaker. I do recall having made use of that code
> once years ago ...
I have never used both options, but one point is that hash_stats() has been
exported and extensions have called it. Is there a possibility that hidden
developer is using?
Anyway, I have no strong opinion. Attached patch does 1) remove HASH_DEBUG and
2) fix broken code with HASH_STATISTICS.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Remove-HASH_DEBUG.patch | application/octet-stream | 1.7 KB |
v2-0002-Fix-broken-code-for-HASH_STATISTICS.patch | application/octet-stream | 701 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-08-15 03:24:40 | Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words |
Previous Message | Xuneng Zhou | 2025-08-15 02:59:29 | Re: memory leak in logical WAL sender with pgoutput's cachectx |