Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup asparallel-restricted.

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