Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date
Msg-id 526495.1755229343@sss.pgh.pa.us
Whole thread Raw
In response to RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Next
From: Shinya Kato
Date:
Subject: Re: Add mode column to pg_stat_progress_vacuum