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

Re: max_wal_senders must die

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_wal_senders must die
Date: 2010-10-27 23:22:37
Message-ID: 1288221757.15416.23.camel@jd-desktop (view raw or whole thread)
Lists: pgsql-hackers
On Wed, 2010-10-27 at 16:13 -0700, Josh Berkus wrote:
> > That's not even considering the extra WAL that is generated when you
> > move up from wal_level = "minimal".  That's probably the bigger
> > performance issue in practice.
> Yeah, I think we've established that we can't change that.
> > I said, and meant, that you didn't make the case at all; you just
> > presumed it was obvious that we should change the defaults to be
> > replication-friendly.  I don't think it is.  As I said, I think that
> > only a minority of our users are going to want replication.
> 50% of PGX's active clients have either already converted to 9.0
> replication or have scheduled a conversion with us.  I expect that to be
> 80% by the time 9.1 comes out, and the main reason why it's not 100% is
> that a few clients specifically need Slony (partial replication or
> similar) or ad-hoc replication systems.

That's interesting. ZERO % of CMD's clients have converted to 9.0 and
many have no current inclination to do so because they are already
easily served by Londiste, Slony, DRBD or Log Shipping.

I would also agree that the minority of our users will want replication.
The majority of CMD customers, PGX customers, EDB Customers will want
replication but that is by far NOT the majority of our (.Org) users.


Joshua D. Drake

-- Major Contributor
Command Prompt, Inc: - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering |

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-10-27 23:45:04
Subject: Re: max_wal_senders must die
Previous:From: Daniel FarinaDate: 2010-10-27 23:18:21
Subject: An unfortunate logging behavior when (mis)configuring recovery.conf

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