Re: Server won't start with fallback setting by initdb.

Greetings Tom Peter, all,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.

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. If this discussion had happened before v10 was
released, I'd be much more open to going with the suggestion of '5', but
forcing users to update their configs for working environments because
we've decided that the default of 10 was too high is just pedantry, in
my opinion.

The original patch proposed strikes me as entirely reasonable, though
given the rarity of seeing a max_connections below 100 in the wild,
unlikely to have any impact on real users. On the other hand, changing
this default setting will actively *break* user environments which are
working today for very questionable benefit- and in a difficult to
realize manner. A user could pg_upgrade and not have any immediate
issues until a weekly cronjob fails or similar. The current value is in
the wild and we've not had reports of performance issues, as best as I
can recall, and in reviewing the various places where max_wal_senders is
used, it seems unlikely that a value of 10 is going to be seriously
worse than a value of 5. If such a case arises, which seems very likely
to be the exception rather than the rule, encouraging them to reduce
max_wal_senders is a straight-forward answer.

Thanks!

Stephen