| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Greg Burd <greg(at)burd(dot)me>, pgsql-hackers(at)postgresql(dot)org |
| Cc: | michael(at)paquier(dot)xyz, greg(at)burd(dot)me, pgsql(at)j-davis(dot)com, thomas(dot)munro(at)gmail(dot)com, exclusion(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, hlinnaka(at)iki(dot)fi |
| Subject: | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |
| Date: | 2026-10-26 15:15:04 |
| Message-ID: | 12CB9268-9A1C-4555-96BB-E3EA01B14C0F@anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On October 26, 2026 10:33:16 AM EDT, Greg Burd <greg(at)burd(dot)me> wrote:
>On 2026-10-26 Andres Freund wrote:
>> I frankly think it's pretty much unacceptable for a niche index like hash
>> to violate the rules like that.
>> [...]
>> It's probably the best answer in the back branches, but I think we
>> shouldn't do this in master.
>
>Thanks for taking the time to review, I'm curious why you used the term
>"niche" with hash indexes. Not related to this topic, just an aside.
I think they're almost unused and don't offer enough advantage over btree (and perform catastrophically bad in many cases). Instead of making them WAL logged a few years back; we should have just ripped them out.
The advantage hash does have, i.e. large key handling, would have better been addressed by adding support to transparently btree indexing a hash of the key + recheck.
Greetings,
Andres
--
Sent from my phone. Please excuse my brevity.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou | 2026-10-26 15:24:30 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Manu | 2026-10-26 14:56:54 | Re: ANSI SQL proposal: SELECT DISTINCT ON (... ORDER BY ...) and UNION DISTINCT ON (... ORDER BY ...) |