On Mon, Feb 18, 2019 at 6:15 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm inclined to think that if we already have lock on the parent > partitioned table (thereby, IIUC, guaranteeing that its partitioning > info can't change) that the order in which we acquire the same lock > level on its partition(s) isn't very important.
Well, as it turns out, there's also a pending patch (series) to remove that guarantee which I would like to get committed. The thread for that is "ATTACH/DETACH PARTITION CONCURRENTLY". I believe I've more or less got the issues with that patch sorted out, but I'm concerned about how it interacts with all of the other things that are currently in flight. Delaying or skipping lock acquisition in some cases and weakening the locks we take in others is not a process that can continue indefinitely without at some point hitting a wall. But that being said, I don't think I quite see how the two things you mention here are connected to each other. If operation A locks parents before children, and operation B also locks parents before children, they generally won't deadlock against each other, even if each locks the children in a different order. An exception would be if the locks involved are of different levels such that the locks on the parents don't conflict but the locks on the children do, e.g. RowExclusiveLock on partitioned tables and AccessExclusiveLock on partitions. But that's a pretty weird setup and I don't know of any current or proposed code that does that. So my question is - what do you mean by the parenthetical note about the partitioning info not changing? Regardless of whether it does or does not, I think the same property holds. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company