Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Дата
Msg-id aJ6sge-FZfsjKK4o@paquier.xyz
обсуждение исходный текст
Ответ на RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Ответы Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Список pgsql-hackers
On Fri, Aug 15, 2025 at 03:22:18AM +0000, Hayato Kuroda (Fujitsu) wrote:
>> 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.

One use case where I've been recently relying on dynahash is the
pgstats shmem code.  While I've not used these symbols, I'm pretty
sure that they could prove useful now that I know about them.  Andres,
an opinion perhaps?

> 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.

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.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления: