Skip site navigation (1) Skip section navigation (2)

Re: max_wal_senders must die

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-27 17:05:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>> 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 

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.

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-10-27 17:37:24
Subject: Re: Simplifying replication
Previous:From: Alex HunsakerDate: 2010-10-27 16:58:38
Subject: Re: add label to enum syntax

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group