Robert Haas <robertmh...@gmail.com> writes: > 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.
> 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. Right, that's the same thing I was trying to say. > ... 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. What I was wondering about was the possibility of the set of tables-that-need-to-be-locked-at-all changing. Maybe that won't create an issue either, but I'm not quite sure. I do have to say that I find the idea of somebody changing the partitioning data concurrently with queries on that partitioned table to be stone cold petrifying. I don't think I believe you can make that work. regards, tom lane