Hi,
On Fri, 15 May 2026 at 20:16, Nathan Bossart <[email protected]> wrote: > On Fri, May 15, 2026 at 04:42:45PM +0200, Álvaro Herrera wrote: > > On 2026-May-15, Nathan Bossart wrote: > >> Yeah, this may be the best option. I'm curious what others think. > > > > I think this bug makes it clear that this code has few enough users, and > > a sufficient number of bugs, that we should just nuke it. Do you really > > want to spend so much time trying to fix it? The module's documentation > > says > > > > (This functionality is long since superseded by the built-in foreign > > key mechanism, of course, but the module is still useful as an > example.) > > > > but I question whether the usefulness value is really there. > > > > Would anyone oppose that? > > Big +1 for removing it in v20. Or maybe even v19. I do think it is worth > trying to fix the more egregious bugs, though, as the code will still be > supported for a few years. > > I agree on the removal part. In the meantime, since the module will still be supported for a while, this seems like a focused fix for the more egregious cache behavior. Attached v3 removes the private SPI plan cache from refint entirely. Both check_primary_key() and check_foreign_key() now prepare their SPI plans per trigger invocation and let SPI_finish() release them. Regards, Ayush
v3-0001-refint-Remove-private-SPI-plan-cache.patch
Description: Binary data
