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

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.

regards, tom lane