Re: [PATCH] refint: Avoid reusing cascade UPDATE plans.

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] refint: Avoid reusing cascade UPDATE plans.
Date: 2026-05-15 14:06:09
Message-ID: agcoUcwlwOIJKecC@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 15, 2026 at 12:13:21PM +0530, Ayush Tiwari wrote:
> After looking at it again, the root issue is that check_foreign_key()'s
> private plan cache is not robust enough for the SQL it stores: the
> cascade UPDATE query text embeds the current NEW key values in its SET
> clause, and the cache itself has no invalidation mechanism, so the
> trigger-name-keyed entries survive a drop and recreate. Rather than
> keep teaching the cache more special cases, v2 just removes the cache
> from check_foreign_key() entirely. Plans are prepared on each trigger
> invocation and released by SPI_finish(). refint is example code, so I
> think the simplicity is worth more than the per-call SPI_prepare.

Yeah, this may be the best option. I'm curious what others think. My
other idea was to use the trigger OID instead of the name as the key, but
that doesn't handle OID reuse. Given this is sample code, that also risks
propagation to third-party code.

> check_primary_key() still uses the existing per-trigger cache; its
> generated SELECT does not embed row values and the same invalidation
> concern is far less interesting there, so I left it alone for now.

Huh? Why is it less interesting? Is it not subject to similar bugs? If
we're going to remove the cache, I think we ought to remove it completely.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-05-15 14:32:14 Re: [PATCH] Fix psql tab completion for REPACK boolean options
Previous Message Álvaro Herrera 2026-05-15 14:04:52 Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt