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.
That's good.
> 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
Interesting. I had somehow gotten into my head that force_parallel_mode would override that. But it doesn't.
So we added that to session initialization in pgBackRest:
Personally I would've done it *just* for 9.6 and not for 10+, but that's mostly semantic :) But if you do it for 9.6 then *eventually* you will be able to retire it.
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.
Right. But since the parameters are flagged as parallel restricted in 10+...
Or are you saying you're worried about other things, completely unrelated to start/stop backup, that the session might run?
