"Hayato Kuroda (Fujitsu)" <kuroda.hay...@fujitsu.com> writes:
> I found that postgres could not be built if a complier option HASH_STATISTICS
> is
> set [1]. Also, I found HASH_DEBUG option caused warnings [2]. Usage of the are
> mentioned at the code comments in dynahash.c.
> I'm not sure whether we would keep supporting them because no one may not have
> used anymore now.
Ugh. I did a bit of "git bisect" work and discovered that:
1. HASH_DEBUG got broken at
commit 44ca4022f3f9297bab5cbffdd97973dbba1879ed
Author: Robert Haas <rh...@postgresql.org>
Date: Wed Mar 23 10:56:23 2016 -0400
Partition the freelist for shared dynahash tables.
and was fixed again at
commit 9d4e56699957b261390c50dcda7f947470017484
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Wed Aug 2 12:16:50 2017 -0400
Remove broken and useless entry-count printing in HASH_DEBUG code.
and then broke again at
commit be0a6666656ec3f68eb7d8e7abab5139fcd47012
Author: Thomas Munro <tmu...@postgresql.org>
Date: Sat Sep 19 11:28:34 2020 +1200
Remove large fill factor support from dynahash.c.
2. HASH_STATISTICS got broken at
commit cc5ef90edd809eaf85e11a0ee251229bbf7ce798
Author: Michael Paquier <mich...@paquier.xyz>
Date: Fri Mar 15 07:57:17 2024 +0900
Refactor initial hash lookup in dynahash.c
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.
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 ...
regards, tom lane
