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. 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. 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. Regards, Surya Poondla
