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

From David Rowley
Subject Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date
Msg-id CAApHDvoccvJ9CG5zx+i-EyCzJbcL5K=CzqrnL_YN59qaL5hiaw@mail.gmail.com
Whole thread Raw
In response to Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
List pgsql-hackers
On Fri, 15 Aug 2025 at 15:42, Michael Paquier <michael@paquier.xyz> wrote:
> It looks like I'm responsible for breaking one of them, at least,
> sorry for that.  As far as I can see, the fixes are not complicated,
> so I'd rather fix and backpatch things rather than removing both as
> both combined can be quite powerful when debugging or improving this
> code.  David, were you planning to do so?  I'd vote for keeping these
> working.

Yes, I'm about to push the HASH_STATISTICS one and backpatch to v17.

I think we should fix and backpatch the HASH_DEBUG one. We can have a
separate debate on removing it in master only. It's hard to imagine
anyone objecting to fixing it, so let's just do that for the time
being.

FWIW, I've no personal need to keep HASH_DEBUG, but if someone does,
then let's keep it. Maybe we can make it use elog(DEBUG<N>) rather
than fprintf and at least build with it in some BF member so we notice
sooner if someone breaks it again. (I've not checked if there's a good
reason why we can't use elog(). Perhaps something dynahash related
happens to early in backend startup...)

David



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Make pgoutput documentation easier to find
Next
From: Michael Paquier
Date:
Subject: Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options