Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

"Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)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 <rhaas(at)postgresql(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)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 <tmunro(at)postgresql(dot)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 <michael(at)paquier(dot)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