On Mon, Oct 16, 2023 at 11:21:20PM -0700, Donghang Lin wrote: > > I've also caught btree posting lists where one TID refers to a '1d' heap > > tuple, while another TID refers to a '24h' heap tuple. amcheck complains. > Index-only scans can return the '1d' bits where the actual tuple had the > '24h' > bits. > > Have a build without the patch. I can't reproduce amcheck complaints in > release mode > where all these statements succeed.
The queries I shared don't create the problematic structure, just an assertion failure. > > * Generic "equalimage" support function. > > * > > * B-Tree operator classes whose equality function could safely be > replaced by > > * datum_image_eq() in all cases can use this as their "equalimage" support > > * function. > It seems to me that as long as a data type has a deterministic sort but not > necessarily be equalimage, > it should be able to support deduplication. e.g for interval type, we add > a byte wise tie breaker > after '24h' and '1day' are compared equally. In the btree, '24h' and '1day' > are still adjacent, > '1day' is always sorted before '24h' in a btree page, can we do dedup for > each value > without problem? Yes. I'm not aware of correctness obstacles arising if one did that.
