On Tue, Oct 10, 2023 at 08:12:36PM -0700, Peter Geoghegan wrote:
> On Tue, Oct 10, 2023 at 6:33 PM Noah Misch <n...@leadboat.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.
