Re: Fast-path FK checks reject valid inserts for domain-typed FK columns

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Junwang Zhao <zhjwpku(at)gmail(dot)com>
Subject: Re: Fast-path FK checks reject valid inserts for domain-typed FK columns
Date: 2026-06-17 02:18:42
Message-ID: CA+HiwqGfvsJeN9fd17aUJjg6XAfkf_4WE=nz2vq7E2U6F5u4_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 16, 2026 at 8:19 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Fri, Jun 12, 2026 at 1:02 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Fri, Jun 12, 2026 at 12:36 PM Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
> > >
> > > Hi,
> > >
> > > Commit 2da86c1 ("Add fast path for foreign key constraint checks") makes
> > > a foreign-key column whose type is a domain over a type different from
> > > the referenced PK reject every valid row:
> > >
> > > CREATE DOMAIN int8dom AS int8;
> > > CREATE TABLE pk (a int4 PRIMARY KEY);
> > > CREATE TABLE fk (b int8dom REFERENCES pk(a));
> > > INSERT INTO fk VALUES (1);
> > > ERROR: no conversion function from int8dom to integer
> > >
> > > It's new in v19 (verified by building 2da86c1^, where the insert
> > > succeeds); no released version is affected. The SPI path still handles
> > > it fine, e.g. with a partitioned PK.
> > >
> > > The fast path is the first caller to pass the cross-type pf_eq_oprs
> > > operator to ri_HashCompareOp(). Its "no cast needed" test,
> > >
> > > if (typeid == righttype)
> > >
> > > fails when the FK column is a domain over righttype (typeid is the
> > > domain OID), so it wrongly concludes no conversion exists and errors out.
> > > Looking through the domain fixes it -- conpfeqop is chosen against the
> > > FK base type, so getBaseType(typeid) == righttype holds for any valid FK:
> > >
> > > - if (typeid == righttype)
> > > + if (getBaseType(typeid) == righttype)
> > >
> > > Patch attached, with a regression test in foreign_key.sql. make check
> > > and the isolation suite pass.
> >
> > Thanks for the report and the patch. Will look next week.
>
> Your analysis looks correct and the patch makes sense. I looked
> through the code and convinced myself the new check is valid.
>
> One nuance: "holds for any valid FK" is true when pfeqop comes
> directly from the index opfamily (right-hand input
> getBaseType(fktype)). The PK = PK fallback uses opcintype instead, but
> there getBaseType can't equal it either, so the test still fails and
> the existing cast lookup runs unchanged.
>
> I polished it a bit for commit: tightened the message and trimmed the
> code comment.
>
> Will push to master tomorrow barring objections.

Done: 68ace967c.

--
Thanks, Amit Langote

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Young 2026-06-17 02:27:57 Re: Fast-path FK checks reject valid inserts for domain-typed FK columns
Previous Message Tender Wang 2026-06-17 02:00:35 Re: assertion failure with unique index + partitioning + join