From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>,
        Amit Langote <amitlangote09@gmail.com>,
        pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Invalidate RI fast-path metadata on operator family
 changes
In-reply-to: 
 <CAMbWs49M_=7ya47-1McJSyW4Bf4haT5EAHq8263znRxOWZ=t5Q@mail.gmail.com>
References: <E1x7p34-00000000Mv7-2O5S@gemulon.postgresql.org>
 <CA+HiwqGitHCmO7nvV4nXXYWDkNYA+zVcJj=JNmL3C1O9B0Gz0A@mail.gmail.com>
 <CA+HiwqHO2xu3eR6bZ99qSQgCTnoS9VC4e0KW25bxE5kmkRMGyQ@mail.gmail.com>
 <e0258f8a-b8f5-411b-963f-5499afe78bf2@gmail.com>
 <CAMbWs49M_=7ya47-1McJSyW4Bf4haT5EAHq8263znRxOWZ=t5Q@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Sun, 20 Sep 2026 09:43:31 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <254194.1789874408.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 19 Sep 2026 23:20:08 -0400
Message-ID: <254195.1789874408@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/254195.1789874408%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Sun, Sep 20, 2026 at 3:00=E2=80=AFAM Alexander Lakhin <exclusion@gmai=
l.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 <=3D(integer,integer),
>> +  operator 3 =3D(integer,integer), operator 4 >=3D(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=3D# create temp table t1 (f1 int, f2 int8);
insert into t1 values (1,1),(1,2),(2,2);
CREATE TABLE
INSERT 0 3
regression=3D# 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 =3D f2;
                                                 QUERY PLAN               =
                                   =

--------------------------------------------------------------------------=
-----------------------------------
 WindowAgg
   Window: w1 AS (PARTITION BY f1 ORDER BY f2 RANGE BETWEEN '1'::bigint PR=
ECEDING AND '1'::bigint FOLLOWING)
   ->  Sort
         Sort Key: f1
         ->  Seq Scan on t1
               Filter: (f1 =3D f2)
(6 rows)

regression=3D# create operator family fam using btree;
CREATE OPERATOR FAMILY
regression=3D# create operator class int_ops for type integer using btree =
family fam as
regression-#  operator 1 <(integer,integer), operator 2 <=3D(integer,integ=
er),
regression-#  operator 3 =3D(integer,integer), operator 4 >=3D(integer,int=
eger),
regression-#  operator 5 >(integer,integer), function 1 btint4cmp(integer,=
integer);
CREATE OPERATOR CLASS
regression=3D# 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 =3D f2;
                                                 QUERY PLAN               =
                                   =

--------------------------------------------------------------------------=
-----------------------------------
 WindowAgg
   Window: w1 AS (PARTITION BY f1 ORDER BY f2 RANGE BETWEEN '1'::bigint PR=
ECEDING AND '1'::bigint FOLLOWING)
   ->  Sort
         Sort Key: f1, f1
         ->  Seq Scan on t1
               Filter: (f1 =3D 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