From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
To: Rushabh Lathia <rushabh.lathia@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: crashes due to setting max_parallel_workers=0
Date: Mon, 27 Mar 2017 01:23:12 +0200
Message-ID: <eb41cd2f-efb7-698d-f6ef-e08e58c5693f@2ndquadrant.com> (raw)
In-Reply-To: <CAKJS1f8x1ptsCidf2FpRXySUJfWLEMjSwxV8_kvozHFPQYaAow@mail.gmail.com>
References: <6ecd6f17-0dcf-1de7-ded8-0de7db1ddc88@2ndquadrant.com>
<CAKJS1f-jnPUKyeF5OGJPNDtkkqMGUOcK+Yn6qjPzP4bTU04WXg@mail.gmail.com>
<CAGPqQf2C6W8aNy9v9ZW2fJs+7p0MoBFfHEtXG8yypimGXTRUvw@mail.gmail.com>
<CAKJS1f8x1ptsCidf2FpRXySUJfWLEMjSwxV8_kvozHFPQYaAow@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
> bug.
>
> ... 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?
regards
--
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:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, david.rowley@2ndquadrant.com, rushabh.lathia@gmail.com, robertmhaas@gmail.com
Subject: Re: crashes due to setting max_parallel_workers=0
In-Reply-To: <eb41cd2f-efb7-698d-f6ef-e08e58c5693f@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox