>> 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
