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

Re: Core team statement on replication in PostgreSQL

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-30 01:25:49
Message-ID: 483F579D.9080307@commandprompt.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
Tom Lane wrote:

>>> There's no point in having read-only slave queries if you don't have a
>>> trustworthy method of getting the data to them.
> 
>> O.k. I was with you until here. Log shipping ala pg_standby works fine
>> now sans read-only slave. No, it isn't out of the box which I can see an
>> argument for but it is certainly trustworthy. Or do you mean the
>> synchronous part?
> 
> How much testing has pg_standby really gotten?  Some, sure, but it's a
> contrib module that wasn't even there before 8.3.  Even ignoring the lag
> issue, I wouldn't trust it a whole lot if I were a DBA responsible for
> valuable data.  As much as some folk would like to think that contrib
> is mainstream, it's not really in the same league as far as testing
> coverage goes.

This is a pretty telling statement.

Sincerely,

Joshua D. Drake


In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2008-05-30 01:26:36
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Aidan Van DykDate: 2008-05-30 00:57:21
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Josh BerkusDate: 2008-05-30 01:26:36
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Aidan Van DykDate: 2008-05-30 00:57:21
Subject: Re: Core team statement on replication in PostgreSQL

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