Greetings Tom Peter, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut <peter.eisentr...@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.
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
Description: PGP signature