On 6/25/20 8:43 AM, Magnus Hagander wrote:
> On Thu, Jun 25, 2020 at 2:11 PM David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> 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
david@pgmasters.net