From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Server won't start with fallback setting by initdb. |
Date: | 2018-03-08 03:02:27 |
Message-ID: | CA+TgmobKRycCL_ke7Fg1Ac_TF1Kzm9_h2Uq2ROD=iqZUs_PkyA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 7, 2018 at 6:43 PM, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-03-08 03:30:24 | Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate. |
Previous Message | David Gould | 2018-03-08 02:27:30 | Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate. |