On Sun, Jan 21, 2018 at 1:39 AM, Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Jan 19, 2018 at 9:29 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > Actually, though it doesn't really look like it from the way things > are structured within nbtsort.c, I don't need to wait for workers to > start up (call the WaitForParallelWorkerToAttach() function you > sketched) before doing any real work within the leader. The leader can > participate as a worker, and only do this check afterwards. That will > work because the leader Tuplesortstate has yet to do any real work. > Nothing stops me from adding a new function to tuplesort, for the > leader, that lets the leader say: "New plan -- you should now expect > this many participants" (leader takes this reliable number from > eventual call to WaitForParallelWorkerToAttach()). > > I admit that I had no idea that there is this issue with > nworkers_launched until very recently. But then, that field has > absolutely no comments. >
It would have been better if there were some comments besides that field, but I think it has been covered at another place in the code. See comments in LaunchParallelWorkers(). /* * Start workers. * * The caller must be able to tolerate ending up with fewer workers than * expected, so there is no need to throw an error here if registration * fails. It wouldn't help much anyway, because registering the worker in * no way guarantees that it will start up and initialize successfully. */ -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
