On Tue, 25 Dec 2018 at 08:15, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Dec 21, 2018 at 6:04 PM David Rowley > <david.row...@2ndquadrant.com> wrote: > > I don't think you need to qsort() the Oids before locking. What the > > qsort() does today is ensure we get a consistent locking order. Any > > other order would surely do, providing we stick to it consistently. I > > think PartitionDesc order is fine, as it's consistent. Having it > > locked in PartitionDesc order I think is what's needed for [1] anyway. > > [2] proposes to relax the locking order taken during execution. > > If queries take locks in one order and DDL takes them in some other > order, queries and DDL starting around the same time could deadlock. > Unless we convert the whole system to lock everything in PartitionDesc > order the issue doesn't go away completely. But maybe we just have to > live with that. Surely we're not going to pay the cost of locking > partitions that we don't otherwise need to avoid a deadlock-vs-DDL > risk, and once we've decided to assume that risk, I'm not sure a > qsort() here helps anything much.
When I said "consistent" I meant consistent over all places where we obtain locks on all partitions. My original v1-0002 patch attempted something like this. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
