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: 4CC920CC0200002500036EE0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

-Kevin

Responses

Browse pgsql-hackers by date

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