Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rename max_parallel_degree?
Date
Msg-id 18837.1465395492@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> On 06/07/2016 11:01 PM, Robert Haas wrote:
>> Here's a patch change max_parallel_degree to
>> max_parallel_workers_per_gather, and also changing parallel_degree to
>> parallel_workers.  I haven't tackled adding a separate
>> max_parallel_workers, at least not yet.  Are people OK with this?

> +1

I've not read the patch in detail, but this sketch of what to do
sounds fine.

>> Note that there is a dump/restore hazard if people have set the
>> parallel_degree reloption on a beta1 install, or used ALTER { USER |
>> DATABASE } .. SET parallel_degree.  Can everybody live with that?
>> Should I bump catversion when applying this?

> IMHO, we just need to call it out in the beta2 announcement.

catversion is not relevant to GUC changes.  It's not really necessary,
because you'd get a clean, easily diagnosed and repaired failure during
postmaster startup anyway.  The point of bumping catversion is to prevent
a postmaster starting when the incompatibility is subtler or harder to
debug than that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116
Next
From: Robert Haas
Date:
Subject: Re: Rename max_parallel_degree?