On 6/24/20 6:27 PM, Tom Lane wrote:
David Steele <da...@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
da...@pgmasters.net
