Re: tablecmds: Deadlock caused by Attach Partition

> On Oct 21, 2026, at 05:24, surya poondla <suryapoondla4(at)gmail(dot)com> 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/