RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date
Msg-id OSCPR01MB1496650D03FA0293AB9C21416F534A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
List 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

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: memory leak in logical WAL sender with pgoutput's cachectx
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words