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

Re: Core team statement on replication in PostgreSQL

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-06-02 15:52:05
Message-ID: 60ej7fkf6i.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
adsmail(at)wars-nicht(dot)de ("Andreas 'ads' Scherbaum") writes:
> On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
>
>> Well, yes, but you do know about archive_timeout, right? No need to wait 
>> 2 hours.
>
> Then you ship 16 MB binary stuff every 30 second or every minute but
> you only have some kbyte real data in the logfile. This must be taken
> into account, especially if you ship the logfile over the internet
> (means: no high-speed connection, maybe even pay-per-traffic) to the
> slave.

If you have that kind of scenario, then you have painted yourself into
a corner, and there isn't anything that can be done to extract you
from it.

Consider: If you have so much update traffic that it is too much to
replicate via WAL-copying, why should we expect that other mechanisms
*wouldn't* also overflow the connection?

If you haven't got enough network bandwidth to use this feature, then
nobody is requiring that you use it.  It seems like a perfectly
reasonable prerequisite to say "this requires that you have enough
bandwidth."
-- 
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/
"There's nothing worse than having only one drunk head."
-- Zaphod Beeblebrox

In response to

Responses

pgsql-hackers by date

Next:From: Jignesh K. ShahDate: 2008-06-02 15:59:21
Subject: Re: Overhauling GUCS
Previous:From: David E. WheelerDate: 2008-06-02 15:39:53
Subject: Re: Case-Insensitve Text Comparison

pgsql-advocacy by date

Next:From: Hannu KrosingDate: 2008-06-02 17:37:59
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Michael Alan BrewerDate: 2008-06-02 14:03:37
Subject: Re: State of PostgreSQL, BOF at OSCON?

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