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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
