On 25 March 2017 at 23:09, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > Also another point which I think we should fix is, when someone set > max_parallel_workers = 0, we should also set the > max_parallel_workers_per_gather > to zero. So that way it we can avoid generating the gather path with > max_parallel_worker = 0.
I see that it was actually quite useful that it works the way it does. If it had worked the same as max_parallel_workers_per_gather, then likely Tomas would never have found this bug. I wondered if there's anything we can do here to better test cases when no workers are able to try to ensure the parallel nodes work correctly, but the more I think about it, the more I don't see wrong with just using SET max_parallel_workers = 0; My vote would be to leave the GUC behaviour as is and add some tests to select_parallel.sql which exploit setting max_parallel_workers to 0 for running some tests. If that's not going to fly, then unless we add something else to allow us to reliably not get any workers, then we're closing to close the door on being able to write automatic tests to capture this sort of bug. ... thinks for a bit.... perhaps some magic value like -1 could be used for this... unsure of how that would be documented though... -- David Rowley 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