On 6/25/20 8:43 AM, Magnus Hagander wrote:
On Thu, Jun 25, 2020 at 2:11 PM David Steele <[email protected]
<mailto:[email protected]>> wrote:
On 6/24/20 6:27 PM, Tom Lane wrote:
>
> I was able to force it like this:
>
> regression=# set force_parallel_mode TO 'on';
> SET
Ah, yes, that works. Now at least I can test it.
> It doesn't seem terribly likely that anybody would be using
> force_parallel_mode = on in production, but perhaps there's some
> reasonable combination of the other parallelization planning GUCs
> that can make this plan look attractive.
I'll also ask the user if they have this GUC enabled.
The user confirmed they are running with force_parallel_mode=on so that
probably explains why we have never seen this in the field before.
Maybe have pgbackrest issue an explicit SET force_parallel_mode=off when
it runs against a 9.6?
According to the documentation the way to disable parallelism is:
set max_parallel_workers_per_gather = 0
So we added that to session initialization in pgBackRest:
https://github.com/pgbackrest/pgbackrest/commit/ea04ec7b3f4c6cf25c1b827c25c6a3c5896159a8
I'm worried that (as Tom said) the planner might find another reason to
choose a parallel query.
I'm looking at this as more than a fix for 9.6. I can't see any reason
for the backup control session to run queries in parallel and possibly
use more resources, so parallelism is disabled for all versions that
support it.
Regards,
--
-David
[email protected]
