Re: pgsql: Invalidate RI fast-path metadata on operator family changes

Hi,

On Sun, Sep 20, 2026 at 12:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > On Sun, Sep 20, 2026 at 3:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> >> I think the window failures are caused by these additions:
> >> +create operator family fam using btree;
> >> +create operator class int_ops for type integer using btree family fam as
> >> + operator 1 <(integer,integer), operator 2 <=(integer,integer),
> >> + operator 3 =(integer,integer), operator 4 >=(integer,integer),
> >> + operator 5 >(integer,integer), function 1 btint4cmp(integer,integer);
>
> > FWIW, this seems to also cause the equivclass failure on widowbird [1].
>
> It's easy to show that this is indeed what is breaking the window.sql
> test cases:
>
> regression=# create temp table t1 (f1 int, f2 int8);
> insert into t1 values (1,1),(1,2),(2,2);
> CREATE TABLE
> INSERT 0 3
> regression=# explain (costs off)
> select f1, sum(f1) over (partition by f1 order by f2
> range between 1 preceding and 1 following)
> from t1 where f1 = f2;
> QUERY PLAN
> -------------------------------------------------------------------------------------------------------------
> WindowAgg
> Window: w1 AS (PARTITION BY f1 ORDER BY f2 RANGE BETWEEN '1'::bigint PRECEDING AND '1'::bigint FOLLOWING)
> -> Sort
> Sort Key: f1
> -> Seq Scan on t1
> Filter: (f1 = f2)
> (6 rows)
>
> regression=# create operator family fam using btree;
> CREATE OPERATOR FAMILY
> regression=# create operator class int_ops for type integer using btree family fam as
> regression-# operator 1 <(integer,integer), operator 2 <=(integer,integer),
> regression-# operator 3 =(integer,integer), operator 4 >=(integer,integer),
> regression-# operator 5 >(integer,integer), function 1 btint4cmp(integer,integer);
> CREATE OPERATOR CLASS
> regression=# explain (costs off)
> select f1, sum(f1) over (partition by f1 order by f2
> range between 1 preceding and 1 following)
> from t1 where f1 = f2;
> QUERY PLAN
> -------------------------------------------------------------------------------------------------------------
> WindowAgg
> Window: w1 AS (PARTITION BY f1 ORDER BY f2 RANGE BETWEEN '1'::bigint PRECEDING AND '1'::bigint FOLLOWING)
> -> Sort
> Sort Key: f1, f1
> -> Seq Scan on t1
> Filter: (f1 = f2)
> (6 rows)
>
> Since t1 is a temp table, the common instability explanations like
> autovacuum don't hold water.
>
> I didn't look closely at why this FK test needs to have a broken
> operator class, but if it does, maybe you could put that whole test
> into a transaction that rolls back, so other sessions never see it.

Was just about to send a patch to do that. Attached here.

I'm thinking of pushing this to master first and see if it helps. I
note in my proposed commit message that back-patching to 19 is
deferred until beta4 freeze is over, but maybe I should not wait until
then?

Thank you all for chiming in.

--
Thanks, Amit Langote