Re: Server won't start with fallback setting by initdb.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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 16:30:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

Done that way. I concur that there's little reason to back-patch
the cross-check change before v10, since the case was even less likely
to happen back when max_wal_senders defaulted to zero. There's some
argument for changing it in v10, but avoiding thrashing translatable
strings in a released branch probably outweighs it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-08 16:45:06 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Anastasia Lubennikova 2018-03-08 16:13:50 Re: WIP: Covering + unique indexes.