On 3 November 2014 17:00, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> The main question is still why any of this is necessary? If we are >> only acquiring fast path locks in workers, what need is there for any >> of this? The leader and workers never conflict with each other, so why >> would they ever wait for each other (except at a point where they are >> actively transferring data), which is the necessary pre-condition for >> a deadlock? >> >> Yes, running a command with a conflicting lock would disrupt the start >> of a parallel operation, but as I said above, the deadlock detector >> will eventually see that and re-arrange us so there is no deadlock. >> >> The only need I can see is if one of the workers/leader requests a >> Strong lock on an object, someone else requests a conflicting lock on >> that object and then we perform a parallel operation ourselves. We >> could easily solve that by saying that you can't go parallel if you >> hold a strong lock AND that workers can't take anything higher than >> RowShareLock, like HS backends. That's good enough for now. > > That would be enough to keep the parallel group from deadlocking with > itself, but it wouldn't be enough to prevent deadlock with other > processes, which is the scenario that actually worries me a lot more. > In particular, I'm worried about deadlocks where some other process > gets sandwiched between two processes from the same parallel group. > That is, let A1 be a parallel group leader and A2 be a process from > the same parallel group, and let B be an unrelated process. I'm > worried about the situation where A2 waits for B which waits for A1 > which (outside the view of the deadlock detector) waits for A2. All > that can happen even if the parallel backends hold no strong locks, > because B can hold strong locks.
OK, I think I'm happy with this as a general point. How will we automatically test this code? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
