| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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-06 22:42:44 |
| Message-ID: | 1ec9f5e2-09fa-4426-07cd-510b47490846@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-03-06 22:53:06 | Re: Server won't start with fallback setting by initdb. |
| Previous Message | Tels | 2018-03-06 22:25:48 | Re: [WIP PATCH] Index scan offset optimisation using visibility map |