The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, failed Spec compliant: not tested Documentation: not tested
Hi, I looked at v13, focusing on apply/build status and relation-lock behavior for reused generic plans after initial partition pruning. I used the v13 series from Amit's 2026-05-29 message, on origin/master at 4b0bf0788b066a4ca1d4f959566678e44ec93422. The series applies cleanly with git am, and git diff --check reports no issues. I first built with: ./configure --prefix="$PWD/pg-install" --without-readline --without-zlib --without-icu make -s -j8 make -s install make -C src/test/regress check passed; all 245 tests passed, including plancache and partition_prune. I also built a cassert/debug tree with: ./configure --prefix="$PWD/pg-install" --without-readline --without-zlib --without-icu --enable-cassert --enable-debug 'CFLAGS=-O0 -g' make -s -j8 make -s install and ran: make -C src/test/regress check which also passed; all 245 tests passed. For the lock behavior, I used a list-partitioned table with force_generic_plan. After the generic plan had been built and then reused, EXECUTE held only the matching child partition lock. For example, EXECUTE q(1) held only the following child lock: manual_prunelock_p1 EXPLAIN EXECUTE behaved the same way on a reused generic plan; EXPLAIN EXECUTE q(2) removed the other subplans and held only the following child lock: manual_prunelock_p2 With enable_partition_pruning = off and a newly prepared statement, executing the same SELECT held all child partition locks: manual_prunelock_p1, manual_prunelock_p2, manual_prunelock_p3 I also ran a bounded cassert/debug stress check around plan invalidation. It did 20 cycles where a child index was created and dropped before EXECUTE, and 20 similar cycles before EXPLAIN EXECUTE. In each cycle, the first execution after invalidation/replanning held all child partition locks, and the next execution reusing the generic plan held only the matching child partition lock. That matches my reading that the patch is reducing locks for reused generic plans, not for the execution that has to rebuild the plan. One behavior I wanted to confirm: prepared UPDATE execution still held all child partition locks in my manual check, including on the second execution where the generic plan was being reused. The test was: prepare upd(int, text) as update stress_prunelock_p set b = $2 where a = $1; Then both: execute upd(3, 'updated-row-3'); and an all-pruned value: execute upd(99, 'no-row'); held: stress_prunelock_p1, stress_prunelock_p2, stress_prunelock_p3, stress_prunelock_p4 pg_prepared_statements showed generic_plans increasing for this prepared statement, so this was not a custom-plan case. Is this expected for ModifyTable/result relations in v13, or did I miss an eligibility condition that prevents pruning-aware locking from being used for this prepared UPDATE case? I saw the recent firstResultRels discussion, but I was not sure whether those changes are intended only to make pruned result-relation initialization safe, or whether actual prepared DML execution is expected to see reduced child partition locking as well. I did not review the broader plancache refactoring design, did not run installcheck-world, and did not test concurrent DDL from a separate session. Regards, Ilmar Yunusov The new status of this patch is: Waiting on Author
