RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

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

In response to

Responses

Browse pgsql-hackers by date

  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