On 2026-Sep-23 at 00:15 UTC, Manu wrote: > If you have a way to reach that branch I am happy to run it.
I can reach it on Linux using v13's existing plancache.sql setup. The new test fails on v13 and passes with Manu's ownership correction. I've combined Manu's correction and the test in the attached patch, which applies on top of v13. The existing case uses EXPLAIN EXECUTE, whose retry is handled by ExplainExecuteQuery(), not PortalLockCachedPlan(). Ordinary EXECUTE exercises the latter. In v13-0004's plancache.sql, immediately before "deallocate inval_during_pruning_q", I ran: execute inval_during_pruning_q; update inval_during_pruning_signal set create_idx = true; execute inval_during_pruning_q; The first EXECUTE caches a valid plan after the earlier DDL. Setting create_idx to true makes the helper create another partition index during initial pruning in the last EXECUTE, invalidating that plan. On v13 over master 3c5d9d914fa, the last command gives: ERROR: plancache reference 0x233e2b0 is not owned by resource owner Portal With Manu's correction it returns the expected row, a = 1. The attachment keeps the existing EXPLAIN EXECUTE case and adds this EXECUTE case. The original core regression, isolation and test_plan_advice suites also pass both with and without Manu's correction. Regards, Rui
0001-Fix-cached-plan-ownership-during-portal-replanning.patch
Description: Binary data
