On 6/25/20 11:02 AM, Magnus Hagander wrote:
On Thu, Jun 25, 2020 at 4:56 PM David Steele <da...@pgmasters.net
<mailto:da...@pgmasters.net>> wrote:
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.
We still support 8.3 so the day when we drop 9.6 support seems so far
away that I'm just not worried about it.
And yes, we still see users with 8.3/8.4 databases. Mostly they just
want to update but backups are an essential part of that process and
some of them are multi-TB databases.
We are planning to drop 8.3 support soon, though, and just tell users to
go back and use X version of pgbackrest if they really need it. This has
more to do with the availability of packages than anything else.
Christoph has built packages all the way back to 8.4 for all recent
Debian distros (thanks Christoph!) but the only place we can get 8.3
packages is on EOL distros, e.g. Ubuntu 12.04.
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?
That's what I'm worried about. We run other queries and functions
besides pg_start_backup()/pg_stop_backup(). None of them need to be
parallelized so why not just disable it? One less variable to worry about.
Regards,
--
-David
da...@pgmasters.net
