From 1722d5eb05d8e5d2e064cd1798abcae4f296ca9d Mon Sep 17 00:00:00 2001 From: Amit Langote Date: Thu, 22 May 2025 14:17:24 +0900 Subject: Revert "Don't lock partitions pruned by initial pruning" As pointed out by Tom Lane, the patch introduced fragile and invasive design around plan invalidation handling when locking of prunable partitions was deferred from plancache.c to the executor. In particular, it violated assumptions about CachedPlan immutability and altered executor APIs in ways that are difficult to justify given the added complexity and overhead. This also removes the firstResultRels field added to PlannedStmt in commit 28317de72, which was intended to support deferred locking of certain ModifyTable result relations. Reported-by: Tom Lane Discussion: https://postgr.es/m/605328.1747710381@sss.pgh.pa.us --- doc/src/sgml/release-18.sgml | 21 --------------------- 1 file changed, 21 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index cdf47ac6d2a..143a8b87647 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -588,27 +588,6 @@ Improve the locking performance of queries that access many relations (Tomas Von - - - - -Avoid the locking of pruned partitions during execution (Amit Langote) -§ -§ -§ -§ - - -