Re: Server won't start with fallback setting by initdb.
От | Tom Lane |
---|---|
Тема | Re: Server won't start with fallback setting by initdb. |
Дата | |
Msg-id | 7405.1520377116@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Server won't start with fallback setting by initdb. (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Server won't start with fallback setting by initdb.
|
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 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 That's "typical"? It sounds like a major installation to me, one that would certainly have had to fool with more settings than just max_wal_senders. Two concurrent pg_basebackups running at all times seems particularly dubious. If we drop the assumption of 2 concurrent pg_basebackups, then your math would lead to a value of 5, which I'd be OK with. regards, tom lane
В списке pgsql-hackers по дате отправления: