Hi,
On 2018-10-04 15:27:59 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I've not really followed this thread, and just caught up to here. It
> > seems entirely unacceptable to not acquire locks on workers to me.
> > Maybe I'm missing something, but why do/did the patches in this thread
> > require that / introduce that? We didn't have that kind of concept
> > before, no? The group locking stuff should rely / require that kind of
> > thing, no?
>
> I'm possibly confused, but I thought that the design of parallel query
> involved an expectation that workers didn't need to get their own
> locks.
Not as far as I'm aware of - but I'm not exactly the expert
there. There's an exception that some lock classes don't conflict
between the leader and the workers - that's group locking
(a1c1af2a1f60). But the locks still have to be acquired, and I think
it's quite dangerous not to do so. The group locking logic is required
because otherwise it'd be trivial to get into deadlocks, and some of the
restrictions around parallel query are required to make that safe.
> What we've determined so far in this thread is that workers *do* get
> their own locks (or did before yesterday), but I'd been supposing that
> that was accidental not intentional.
I don't think it was accidental.
Greetings,
Andres Freund
