Re: RI fast path gets cross-type foreign keys wrong

On Sat, Aug 1, 2026 at 8:49 Amit Langote <amitlangote09(at)gmail(dot)com> wrote:

> On Sat, Aug 1, 2026 at 8:33 Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
>> The attached isolation test patch (written by Claude code) shows that
>> the new RI fast path can get some things wrong when a foreign key uses
>> a cross-type equality operator.
>>
>> The test has two permutations differing only in the primary key's type
>> -- date against a timestamp FK in the first, timestamp against
>> timestamp in the second. The interleaving is identical and the
>> referenced key is present throughout, so both should behave the same
>> way. The second succeeds (which is correct), while the first fails
>> with a foreign key violation (which is incorrect).
>>
>> The fast path was introduced by b7b27eb41. This is an issue on 19 and
>> master only.
>
>
> Thanks Peter for the report. I’m on vacation atm, will take a look when I
> get back next week.
>

Still away, but couldn’t help reading the code on my phone.

The recheck block in ri_FastPathFlushArray() appears to put the key it has
just read out of the locked tuple (found_val) into sk_argument, and then
pass that same slot to recheck_matched_pk_tuple(). If I’m reading that
right, both operands come from the locked tuple, so it compares the key
with itself and since sk_argument is the right-hand operand, which on a
cross-type operator is the FK-typed side, the PK value there gets read as
an FK value. That would make the same-type case pass trivially and the
cross-type case fail always, which seems to fit what Peter is seeing.

If that’s really what’s going on, maybe the recheck can just go away,
because the loop a few lines further down in the same scan iteration already
compares found_val against the buffered FK values. I’ll look at it properly
next week.

- Amit

>