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