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

From Richard Guo
Subject Re: pgsql: Invalidate RI fast-path metadata on operator family changes
Date
Msg-id CAMbWs49M_=7ya47-1McJSyW4Bf4haT5EAHq8263znRxOWZ=t5Q@mail.gmail.com
Whole thread
In response to Re: pgsql: Invalidate RI fast-path metadata on operator family changes  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: pgsql: Invalidate RI fast-path metadata on operator family changes
List pgsql-committers
On Sun, Sep 20, 2026 at 3:00 AM Alexander Lakhin <exclusion@gmail.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 seems to me what happens is that the new family adds operator 3
=(bigint,bigint), i.e. int8eq.  So in

  select * from ec0 a, ec1 b
  where a.ff = b.ff and a.ff = 43::bigint::int8alias1;

get_mergejoin_opfamilies() gives a.ff = b.ff {integer_ops, fam} while
a.ff = 43::int8alias1 stays {integer_ops}, and process_equivalence()
requires those lists to be equal().  The two clauses land in separate
ECs, the constant never propagates to b.ff, and we get

  -         Index Cond: (ff = '43'::int8alias1)
  +         Index Cond: (ff = a.ff)

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=widowbird&dt=2026-09-19%2019%3A50%3A41

- Richard



pgsql-committers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: pgsql: Invalidate RI fast-path metadata on operator family changes
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Invalidate RI fast-path metadata on operator family changes