Re: interval_ops shall stop using btequalimage (deduplication)

On Tue, Oct 10, 2023 at 08:12:36PM -0700, Peter Geoghegan wrote:
> On Tue, Oct 10, 2023 at 6:33 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > interval_ops, however, recognizes equal-but-distinguishable values:
>
> > Fails with:
> >
> > 2498151 2023-10-10 05:06:46.177 GMT DEBUG: building index "ti" on table "t" serially
> > 2498151 2023-10-10 05:06:46.178 GMT DEBUG: index "ti" can safely use deduplication
> > TRAP: failed Assert("!itup_key->allequalimage || keepnatts == _bt_keep_natts_fast(rel, lastleft, firstright)"), File: "nbtutils.c", Line: 2443, PID: 2498151
>
> Nice catch.
>
> Out of curiosity, how did you figure this out? Did it just occur to
> you that interval_ops had a behavior that made deduplication unsafe?
> Or did the problem come to your attention after running amcheck on a
> customer database? Or was it something else?

My friend got an amcheck "lacks matching index tuple" failure, and they asked
me about it. I ran into the assertion failure while reproducing things.

> I'm a little surprised that it took this long to notice
> the interval_ops issue.

Agreed. I don't usually store interval values in tables, and I'm not sure
I've ever indexed one. Who knows.

> Do we really need to change the catalog contents when backpatching?

Not really. I think we usually do. On the other hand, unlike some past
cases, there's no functional need for the catalog changes. The catalog
changes just get a bit of efficiency. No strong preference here.