Re: generic plans and "initial" pruning

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