Re: [HACKERS] Replication/backup defaults - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] Replication/backup defaults
Date
Msg-id CABUevEzmJDKZjue8p7wvjoO7b=FH3+rCJVXUGXJzWcwQUTHzZw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Replication/backup defaults  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Replication/backup defaults  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


On Sat, Jan 7, 2017 at 1:27 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 1/5/17 12:01 PM, Andres Freund wrote:
> On 2017-01-05 08:38:32 -0500, Peter Eisentraut wrote:
>> I also suggest making the defaults for both 20 instead of 10.  That
>> leaves enough room that almost nobody ever has to change them, whereas
>> 10 can be a bit tight for some not-outrageous installations (8 standbys
>> plus backup?).
>
> I'm afraid we need to add initdb integration / testing for those. I mean
> we have initdb test down to 10 connections to deal with limited
> resources...

Those initdb defaults were last touched in 2005, before the use of
System V shared memory was reduced to a minimum.  It might be worth
revisiting that.  The only way to end up with a low number of connection
slots would seem to be a very low semaphore configuration.

In the build farm, I have found 6 critters that do not end up with the
100/128MB setting: sidewinder, curculio, coypu, brolga, lorikeet,
opossum.  I wonder what limitations initdb is bumping against.


Since you lookeda t the data -- they did not end up with 100, but what's the lowest they did end up with? Did they go all the way down to 10? 


--

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [HACKERS] Support for pg_receivexlog --format=plain|tar
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project