On 03/25/2017 02:01 PM, David Rowley wrote:
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;

It's demonstrably a valid way to disable parallel queries (i.e. there's nothing wrong with it), because the docs say this:

   Setting this value to 0 disables parallel query execution.

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

... thinks for a bit....

perhaps some magic value like -1 could be used for this... unsure of
how that would be documented though...

I agree it'd be very useful to have a more where we generate parallel plans but then prohibit starting any workers. That would detect this and similar issues, I think.

I'm not sure we need to invent a new magic value, though. Can we simply look at force_parallel_mode, and if it's 'regress' then tread 0 differently?


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to