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.
Maybe have pgbackrest issue an explicit SET force_parallel_mode=off when it runs against a 9.6?
> 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.
+1. Seems infrequent enough or we would've heard much about it before. And it's not going to be *all* that common with brand new clusters on 9.6 these days (I hope).