Re: max_wal_senders must die

>> Josh has completely failed to make a case that
>> that should be the default.
>
> Agreed.

In what way have a failed to make a case?

1. The more settings our users need to change to make replication work, 
the more difficult and frustrating it is for them.  See Robert's example 
of the current work path earlier in this thread.

2. Therefore it benefits our users to have as many settings which can be 
set without penalty default to ones which are replication-compatible.

3. If there is no specific performance penalty for the master being 
willing to accept a replication connection, then placing a limit on the 
# of potential replication connections is an obscure high-end corner 
case, and the common case is the user who wants no limit.

This seems like a very simple case of making things easier for our users 
... setting a default to what most users want.  Why is it opaque to you 
guys?

In each step of working on replication management and configuration, I 
see this list focusing on high-end corner cases and ignoring 99% of our 
users, who just want a "replication = on" switch.  I've seen this in 
this discussion, and I've seen it in the sync rep discussion.  While 
it's fun to talk about huge pools of servers with quorum commit and 
load-balancing connection ratios, 99% of our users just have 2 servers 
they want to replicate, and do it in a low administration way.

--                                   -- Josh Berkus                                     PostgreSQL Experts Inc.
                           http://www.pgexperts.com