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

Re: max_wal_senders must die

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <jd(at)commandprompt(dot)com>,<robertmhaas(at)gmail(dot)com>
Cc: <josh(at)agliodbs(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-28 12:05:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Joshua D. Drake"  wrote:
> On Wed, 2010-10-27 at 19:52 -0400, Robert Haas wrote:
>> Josh Berkus  wrote:
>>> *you don't know* how many .org users plan to implement
>>> replication, whether it's a minority or majority.
>> None of us know. What I do know is that I don't want PostgreSQL to
>> be slower out of the box.
> Poll TIME!
If you do take a poll, be careful to put in an option or two to deal
with environments where there is "surgical" implementation of
replication features.  We'll almost certainly be using SR with a
custom WAL receiver as part of our solution for our biggest and most
distributed data set (circuit court data), but an "out of the box"
drop in usage there is not in the cards anytime soon; whereas we're
already using HS/SR "out of the box" for a small RoR web app's data.
By the way, the other three DBAs here implemented the HS/SR while I
was out for a couple days while my dad was in the hospital (so they
didn't want to even bother me with a phone call).  They went straight
from the docs, without the benefit of having tracked any PostgreSQL
lists.  They told me that it was working great once they figured it
out, but it was confusing; it took them a lot of time and a few false
starts to get it working.  I've been trying to get details to support
an improvement in documentation, but if those guys had problems I
agree we need to do *something* to make this simpler -- they're
bright professionals who manage hundreds of PostgreSQL databases on a
full time basis.


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-10-28 12:55:40
Subject: revision of todo: NULL for ROW variables
Previous:From: Heikki LinnakangasDate: 2010-10-28 11:35:23
Subject: Re: plan time of MASSIVE partitioning ...

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