> On Oct 21, 2026, at 05:24, surya poondla <[email protected]> wrote: > > Hi Chao, > > Thanks for v2. I applied both patches to the current master, they apply > cleanly and build without warnings. I ran the new > partition-attach-lock-order isolation test together with > partition-concurrent-attach and partition-drop-index-locking against the > v2 build, and all three pass. > > The retry handling looks right to me. RangeVarGetRelidExtended() calls the > callback before each lock attempt, including retries, so a same-OID > retry keeps the ancestor locks, a different-OID retry releases them before > locking the new ones, and a name that no longer resolves releases > the old ancestors and locks nothing. Following detach-pending links also now > matches what generate_partition_qual() code. > > Two small comments, neither blocking: > 1. lock_partition_ancestors() is also called for a top-level partitioned > table, which has no parent, so it scans pg_inherits and finds nothing. > Checking get_rel_relispartition(relid) in the callback before calling it > would skip that. It would also fit the comment on > get_partition_ancestors(), which says ancestors should only be looked up for > a partition. >
Good point. Addressed in v3. > 2. The ancestors are computed before the target is locked and aren't > rechecked afterwards, so if the target is reparented in between, > generate_partition_qual() could still walk an ancestor that wasn't > pre-locked. RangeVarCallbackForDropRelation() has the same gap, so I > think it's acceptable, but a short comment saying so might help. > Add a comment for that in v3. > One wording nit in the commit message: "the partition is already locked > during parse analysis" is only true for a freshly parsed statement. For a > cached plan (prepared statement, PL/pgSQL) the lock is taken in the plancache > before execution. Something like "the partition is already > locked before its ancestors are locked to check partition constraints" is > true on both paths. The phrase came from my first mail, so that one is > on me. Updated 0001’s commit message. PFA v3: * 0001 - addressed Surya’s comments * 0002 - unchanged Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v3-0001-Prevent-deadlock-between-ALTER-TABLE-recursion-an.patch
Description: Binary data
v3-0002-Add-isolation-test-for-ATTACH-PARTITION-lock-orde.patch
Description: Binary data
