Horton

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: David Rowley <dgrowleyml@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-15T07:09:09Z
Lists: pgsql-hackers 
On Fri, Aug 15, 2025 at 06:37:44PM +1200, David Rowley wrote:
> I think the votes to keep it should outweigh the votes to get rid of
> it, as someone voting to keep it probably has some idea that it'll be
> useful to them, and keeping it shouldn't really hinder the people who
> don't want it. I think Michael has voted to keep it.
> 
> Michael, any thoughts on switching from stderr to elog(DEBUG)?

You mean to do that for both flags, right?  That would be OK for me.

> And also about defining HASH_DEBUG on one of your BF members?

Sure, I'll do that for both HASH_DEBUG and HASH_STATISTICS if we
decide to keep both and that a fix is applied.  We've proven to be bad
at breaking the two of them.
--
Michael

Commits

  1. Remove HASH_DEBUG output from dynahash.c

  2. Use elog(DEBUG4) for dynahash.c statistics output

  3. Fix invalid format string in HASH_DEBUG code

  4. Fix failing -D HASH_STATISTICS builds

  5. Refactor initial hash lookup in dynahash.c

  6. Remove large fill factor support from dynahash.c.

  7. Remove broken and useless entry-count printing in HASH_DEBUG code.

  8. Partition the freelist for shared dynahash tables.