On 6/24/20 6:27 PM, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
>> ... So apparently it is possible. To get them working as soon as possible I
>> recommended that they run:
>> alter role postgres set max_parallel_workers_per_gather = 0;
>> And that solved their problem. 9.6 is getting on in years so I'm not
>> sure how much time/effort we want to spend on this, but I figured it was
>> worth mentioning.
>
>> I did another round of trying to reproduce the issue but came up short a
>> second time.
>
> 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.
> I'm kind of inclined not to bother with a code fix at this late date,
> given that we've had so few trouble reports. The right answer is
> to tell anyone who's affected to fix their catalogs manually, viz
>
> update pg_proc set proparallel = 'r' where proname = 'pg_start_backup';
> update pg_proc set proparallel = 'r' where proname = 'pg_stop_backup';
Only pg_stop_backup() needs to be updated, but that's probably the best
solution.
> If we had back-patched 9fe3c644a (sans catversion bump of course)
> at the time, then initdb's done with 9.6.3 or later would have gotten
> this right. In hindsight, not doing that was clearly wrong. But it
> seems a bit late to do it now.
OK by me.
Regards,
--
-David
david@pgmasters.net