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

Re: Core team statement on replication in PostgreSQL

From: David Fetter <david(at)fetter(dot)org>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-29 15:53:03
Message-ID: 20080529155303.GQ16218@fetter.org (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
> On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote:
> > This part is a deal-killer.  It's a giant up-hill slog to sell
> > warm standby to those in charge of making resources available
> > because the warm standby machine consumes SA time, bandwidth,
> > power, rack space, etc., but provides no tangible benefit, and
> > this feature would have exactly the same problem.
> > 
> > IMHO, without the ability to do read-only queries on slaves, it's
> > not worth doing this feature at all.
> 
> The only question I have is... what does this give us that PITR
> doesn't give us?

It looks like a wrapper for PITR to me, so the gain would be ease of
use.

Cheers,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2008-05-29 15:56:16
Subject: Re: [PERFORM] Memory question on win32 systems
Previous:From: Dave PageDate: 2008-05-29 15:52:48
Subject: Re: [PERFORM] Memory question on win32 systems

pgsql-advocacy by date

Next:From: Robert TreatDate: 2008-05-29 15:55:10
Subject: Re: State of PostgreSQL, BOF at OSCON?
Previous:From: Josh BerkusDate: 2008-05-29 15:49:54
Subject: Re: Core team statement on replication in PostgreSQL

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