On Tue, Jan 23, 2018 at 9:02 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: >> Yes, this is what I am trying to explain on parallel create index >> thread. I think there we need to either use >> WaitForParallelWorkersToFinish or WaitForParallelWorkersToAttach (a >> new API as proposed in that thread) if we don't want to use barriers. >> I see a minor disadvantage in using WaitForParallelWorkersToFinish >> which I will say on that thread. > > Ah, I see. So if you wait for them to attach you can detect > unexpected dead workers (via shm_mq_receive), at the cost of having > the leader wasting time waiting around for forked processes to say > hello when it could instead be sorting tuples.
The leader can go ahead and sort before calling something like a new WaitForParallelWorkersToAttach() function (or even WaitForParallelWorkersToFinish()). If we did add a WaitForParallelWorkersToAttach() function, then the performance hit would probably not be noticeable in practice. The parallel_leader_participates case would still work without special care (that's the main hazard that makes using a barrier seem unappealing). -- Peter Geoghegan
