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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
Date: 2020-06-25 12:43:50
Message-ID: CABUevEzPYSC9Deveh6iFXJ9SAVgWX-7Kxi6gum2tDy32enB+ug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Thu, Jun 25, 2020 at 2:11 PM David Steele <david(at)pgmasters(dot)net> wrote:

> On 6/24/20 6:27 PM, Tom Lane wrote:
> > David Steele <david(at)pgmasters(dot)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).

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message David Steele 2020-06-25 14:56:28 Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
Previous Message David Steele 2020-06-25 12:11:49 Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.