Re: Server won't start with fallback setting by initdb. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Server won't start with fallback setting by initdb.
Date
Msg-id 1ec9f5e2-09fa-4426-07cd-510b47490846@2ndquadrant.com
Whole thread Raw
In response to Re: Server won't start with fallback setting by initdb.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Server won't start with fallback setting by initdb.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 is max_wal_senders = 10.
> Where did that come from?

Let's see.  A typical installation might need:

1 for pg_receivewal for continuous backup
2 for pg_basebackup
2 for if pg_basebackup gets interrupted and it takes 2 hours to free the
TCP/IP connections
1 for a standby connection
1 for a second standby connection, for making infrastructure changes

The purpose of raising the defaults to 10 was so that most users
wouldn't need to make changes, making it easier to access "proper"
backups and HA.  By my account, if the default were less than 7, the
setting would be insufficient to satisfy that goal.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: "Tels"
Date:
Subject: Re: [WIP PATCH] Index scan offset optimisation using visibility map
Next
From: Tom Lane
Date:
Subject: Re: Server won't start with fallback setting by initdb.