Re: max_wal_senders must die - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: max_wal_senders must die
Date
Msg-id 4CC920CC0200002500036EE0@gw.wicourts.gov
Whole thread Raw
In response to max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Responses Re: max_wal_senders must die
List 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.
-Kevin


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: plan time of MASSIVE partitioning ...
Next
From: Pavel Stehule
Date:
Subject: revision of todo: NULL for ROW variables