On Wed, Mar 7, 2018 at 6:43 PM, Michael Paquier <mich...@paquier.xyz> wrote: > On Wed, Mar 07, 2018 at 06:39:32PM -0500, Tom Lane wrote: >> OK, seems like I'm on the short end of that vote. I propose to push the >> GUC-crosschecking patch I posted yesterday, but not the default-value >> change, and instead push Kyotaro-san's initdb change. Should we back-patch >> these things to v10 where the problem appeared? > > I would vote for a backpatch. If anybody happens to run initdb on v10 > and gets max_connections to 10, that would immediately cause a failure. > We could also wait for sombody to actually complain about that, but a > bit of prevention does not hurt to ease future user experience on this > released version.
In theory, back-patching the GUC-crosschecking patch could cause the cluster to fail to restart after the upgrade. It's pretty unlikely. We have to postulate someone with, say, default values but for max_connections=12. But it's not impossible. I would be inclined to back-patch the increase in the max_connections fallback from 10 to 20 because that fixes a real, if unlikely, failure mode, but treat the GUC cross-checking stuff as a master-only improvement. Although it's unlikely to hurt many people, there's no real upside. Nobody is going to say "boy, it's a good thing they tidied that GUC cross-checking in the latest major release -- that really saved my bacon!". Nothing is really broken as things stand. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
