Robert Haas writes:
> On Wed, Mar 7, 2018 at 6:43 PM, Michael Paquier 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
>>> chan
On Wed, Mar 7, 2018 at 6:43 PM, Michael Paquier 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 Kyotar
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 t
Robert Haas writes:
> On Tue, Mar 6, 2018 at 10:51 PM, Stephen Frost wrote:
>> Changing the defaults to go back down strikes me as an entirely wrong
>> approach after we've had a release with the higher defaults without
>> seriously compelling arguments against, and I don't agree that we've had
>
On Tue, Mar 6, 2018 at 10:51 PM, Stephen Frost wrote:
> Changing the defaults to go back down strikes me as an entirely wrong
> approach after we've had a release with the higher defaults without
> seriously compelling arguments against, and I don't agree that we've had
> such a case made here. I
Greetings Tom Peter, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 3/4/18 15:31, Tom Lane wrote:
> >> Then, seeing that the factory defaults are ReservedBackends = 3 and
> >> max_wal_senders = 10, something's got to give; there's no way that
> >> max_connections =
Peter Eisentraut writes:
> On 3/4/18 15:31, Tom Lane wrote:
>> Then, seeing that the factory defaults are ReservedBackends = 3 and
>> max_wal_senders = 10, something's got to give; there's no way that
>> max_connections = 10 can work with those. But what I would argue is that
>> of those three ch
I wrote:
> Therefore, the condition that actually ought to be getting enforced here
> is either "ReservedBackends + max_wal_senders < MaxConnections", or
> "ReservedBackends + max_wal_senders <= MaxConnections", depending on
> whether you think it's appropriate to require at least one not-reserved-
On 3/4/18 15:31, Tom Lane wrote:
> Then, seeing that the factory defaults are ReservedBackends = 3 and
> max_wal_senders = 10, something's got to give; there's no way that
> max_connections = 10 can work with those. But what I would argue is that
> of those three choices, the least defensible one
Michael Paquier writes:
> On Sun, Mar 04, 2018 at 03:31:31PM -0500, Tom Lane wrote:
>> ... But what I would argue is that
>> of those three choices, the least defensible one is max_wal_senders = 10.
>> Where did that come from? What fraction of real-world installations will
>> need that? We don'
On Sun, Mar 04, 2018 at 03:31:31PM -0500, Tom Lane wrote:
> Then, seeing that the factory defaults are ReservedBackends = 3 and
> max_wal_senders = 10, something's got to give; there's no way that
> max_connections = 10 can work with those. But what I would argue is that
> of those three choices,
Robert Haas writes:
> On Fri, Feb 9, 2018 at 3:08 AM, Kyotaro HORIGUCHI
> wrote:
>> I think that we can safely increase the fallback value to 20 with
>> which regtests are known not to fail.
> I propose an alternative fix: let's instead change the code like this:
> if (max_wal_senders >
On Fri, Feb 9, 2018 at 3:08 AM, Kyotaro HORIGUCHI
wrote:
> I'm not sure such a case happens in the real world nowadays,
> initdb uses the fallback value of max_connections=10. But it is
> out of favor of server since it is not larger than
> max_wal_senders(10).
>
>> postgres: max_wal_senders must
On Wed, Feb 14, 2018 at 10:08:06AM +0900, Kyotaro HORIGUCHI wrote:
> Definitely. The another rationale for the value is that regtest
> fails with the numbers less than 20. So it's not 11 but
> 20. Currently regtest should succeed with that number of
> connections as written in parallel_schedule and
Hello,
At Mon, 12 Feb 2018 22:28:15 +0900, Michael Paquier wrote
in <20180212132815.gb18...@paquier.xyz>
> On Fri, Feb 09, 2018 at 05:08:23PM +0900, Kyotaro HORIGUCHI wrote:
> > > postgres: max_wal_senders must be less than max_connections
> >
> > I think that we can safely increase the fallbac
On Fri, Feb 09, 2018 at 05:08:23PM +0900, Kyotaro HORIGUCHI wrote:
> > postgres: max_wal_senders must be less than max_connections
>
> I think that we can safely increase the fallback value to 20 with
> which regtests are known not to fail. I believe that is
> preferable than explicitly reducing m
Hello.
I'm not sure such a case happens in the real world nowadays,
initdb uses the fallback value of max_connections=10. But it is
out of favor of server since it is not larger than
max_wal_senders(10).
> postgres: max_wal_senders must be less than max_connections
I think that we can safely inc
17 matches
Mail list logo
