Re: Rename max_parallel_degree?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>,
Peter Geoghegan <pg@heroku.com>,
Noah Misch <noah@leadboat.com>,
David Rowley <david.rowley@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Magnus Hagander <magnus@hagander.net>,
Bruce Momjian <bruce@momjian.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-08T14:18:12Z
Lists: 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