Hi,

On Sun, Sep 20, 2026 at 12:20 PM Tom Lane <[email protected]> wrote:
> Richard Guo <[email protected]> writes:
> > On Sun, Sep 20, 2026 at 3:00 AM Alexander Lakhin <[email protected]> 
> > 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

Attachment: v1-0001-Attempt-to-fix-test-interference-from-foreign_key.patch
Description: Binary data

Reply via email to