Horton

RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread View on postgr.es
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Tom Lane' <tgl@sss.pgh.pa.us>
Cc: "'pgsql-hackers@lists.postgresql.org'" <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-15T03:22:18Z
Lists: pgsql-hackers

Attachments

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

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.