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.
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 |