Re: [PATCH] dynahash.c refactoring

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] dynahash.c refactoring
Date: 2026-11-05 08:47:20
Message-ID: 4ac9c338-e6fd-4279-a9ff-87b608c7dceb@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.11.26 11:19, Aleksander Alekseev wrote:
> Hi Peter,
>
>>> 0001: hash_freeze() has not been used since 5dfc198146 (Oct 2016). I
>>> suggest removing it.
>>
>> This seems alright. If someone needs it, we can put it back.
>>
>>> 0002: hash_destroy() is the only caller of hash_stats(). I suggest
>>> making the function static and place it under `#ifdef
>>> HASH_STATISTICS`.
>>
>> I don't think this is an improvement. In general, I would like to keep
>> the amount of code covered by #ifdef's as small as possible. That way,
>> we reduce the chances that some code rots because it is not compiled by
>> default. We could make the function static, but I would avoid the
>> additional #ifdef's.
>
> Thanks for the feedback. Here are the corrected patches.

I have committed the patch to remove hash_freeze().

About hash_stats(), the header comment in dynahash.c still mentioned
hash_stats() as a public interface. That would have to be adjusted. On
further thought, let's just leave that alone. There is nothing wrong
with having this as an external interface, for example to debug the hash
table usage of some algorithm.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-11-05 08:54:20 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Xuneng Zhou 2026-11-05 08:47:14 Re: Preferred way to submit a very large batch of bugs?