The lock taken on the parent is either ShareUpdateExclusiveLock or AccessExclusiveLock depending on whether CONCURRENTLY is specified or not. Maybe that should be considered also when locking the children.
I've updated the patch that way. (Also, reintroduced the slightly longer commit message that I had added in v3. :))
> If CONCURRENTLY is specified, ... the second transaction acquires SHARE UPDATE EXCLUSIVE on the partitioned table and ACCESS EXCLUSIVE on the partition, and the detach process completes.
In comment to find_all_inheritors():
> The specified lock type is acquired on all child relations (but not on the given rel; caller should already have locked it)
So I conclude that it is done in a right way in v3 with ACCESS_EXCLUSIVE lock.
Also I'd recommend removing the link to a discussion from the test. Anyway we have link in a commit message.