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 15:02:52 |
Message-ID: | CABUevEzv7CbK+DWvGTyPh19f=pa931C6dMvwPNeQ7d7Edf+Uvw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Thu, Jun 25, 2020 at 4:56 PM David Steele <david(at)pgmasters(dot)net> wrote:
> On 6/25/20 8:43 AM, Magnus Hagander wrote:
> > On Thu, Jun 25, 2020 at 2:11 PM David Steele <david(at)pgmasters(dot)net
> > <mailto:david(at)pgmasters(dot)net>> wrote:
> > On 6/24/20 6:27 PM, Tom Lane wrote:
> > >
> > > 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.
>
> The user confirmed they are running with force_parallel_mode=on so that
> probably explains why we have never seen this in the field before.
>
That's good.
> Maybe have pgbackrest issue an explicit SET force_parallel_mode=off when
> > it runs against a 9.6?
>
> According to the documentation the way to disable parallelism is:
>
> set max_parallel_workers_per_gather = 0
>
Interesting. I had somehow gotten into my head that force_parallel_mode
would override that. But it doesn't.
So we added that to session initialization in pgBackRest:
>
>
> https://github.com/pgbackrest/pgbackrest/commit/ea04ec7b3f4c6cf25c1b827c25c6a3c5896159a8
Personally I would've done it *just* for 9.6 and not for 10+, but that's
mostly semantic :) But if you do it for 9.6 then *eventually* you will be
able to retire it.
I'm worried that (as Tom said) the planner might find another reason to
> choose a parallel query.
>
> I'm looking at this as more than a fix for 9.6. I can't see any reason
> for the backup control session to run queries in parallel and possibly
> use more resources, so parallelism is disabled for all versions that
> support it.
>
Right. But since the parameters are flagged as parallel restricted in 10+...
Or are you saying you're worried about other things, completely unrelated
to start/stop backup, that the session might run?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-25 15:17:20 | Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted. |
Previous Message | David Steele | 2020-06-25 14:56:28 | Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted. |