On Tue, 25 Dec 2018 at 08:15, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Dec 21, 2018 at 6:04 PM David Rowley
> <david.rowley@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