Re: SQL:2011 application time

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: SQL:2011 application time
Date: 2025-01-27 15:56:18
Message-ID: 23923ad9-a468-4c2e-8926-e47d15d1eb23@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.01.25 00:20, Paul Jungwirth wrote:
> What about caching the FK's query plan? Could the RESTRICT test ever
> reuse the constraint oid from the NO ACTION tests just above it? I'm
> pretty sure that's not supposed to happen, but if it used a plan
> generated from the NO ACTION SQL, it would exhibit the behavior we're
> seeing. It also makes sense why it only appeared after 1772d554b0.

I think this call in ri_restrict()

ri_BuildQueryKey(&qkey, riinfo, RI_PLAN_RESTRICT);

needs to use a different third argument for NO ACTION vs. RESTRICT,
since we are now sometimes using different queries for them.

However, the RI_QueryKey also uses the constraint OID as part of the
hash key, so even this mistake would not trigger any bad effect unless
we also have OID collisions?

I'm also not able to reproduce this exact regression.diffs pattern by
messing with various conditionals in ri_restrict(), to intentionally
cause a confusion between the NO ACTION and RESTRICT cases.

Nevertheless, this line of investigation seems most plausible to me at
the moment.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2025-01-27 16:09:31 Re: Statistics Import and Export
Previous Message Peter Eisentraut 2025-01-27 15:47:35 Re: SQL:2011 application time