Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date: 2025-08-15 03:42:23
Message-ID: 526495.1755229343@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> writes:
>> 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?

Seems unlikely. They couldn't count on it doing anything at all
in a standard build. Moreover, even if HASH_STATISTICS is defined,
what it will do is print to stderr which is hardly a production-
friendly behavior. So on the whole I'd bet lunch that no one
depends on hash_stats().

In any case, we'd be talking about a change in master only,
not something we'd back-patch. So there would be time for
people to complain if anyone really cares.

> Anyway, I have no strong opinion. Attached patch does 1) remove HASH_DEBUG and
> 2) fix broken code with HASH_STATISTICS.

Whatever we do with this, let's do it in two separate patches,
just in case someone argues for reverting one or the other.
The issues don't seem to me to be fundamentally connected.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinya Kato 2025-08-15 04:19:02 Re: Add mode column to pg_stat_progress_vacuum
Previous Message Michael Paquier 2025-08-15 03:41:53 Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options