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

Re: Core team statement on replication in PostgreSQL

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: David Fetter <david(at)fetter(dot)org>
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 17:39:48
Message-ID: Pine.GSO.4.64.0805291328110.10679@westnet.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Thu, 29 May 2008, David Fetter wrote:

> 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.

This is an interesting commentary on the priorities of the customers 
you're selling to, but I don't think you can extrapolate from that too 
much.  The deployments I normally deal with won't run a system unless 
there's a failover backup available, period, and the fact that such a 
feature is not integrated into the core yet is a major problem for them. 
Read-only slaves is a very nice to have, but by no means a prerequisite 
before core replication will be useful to some people.  Hardware/machine 
resources are only worth a tiny fraction of what the data is in some 
environments, and in some of those downtime is really, really expensive.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2008-05-29 17:41:32
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Tom LaneDate: 2008-05-29 17:37:14
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Jeff DavisDate: 2008-05-29 17:41:32
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Tom LaneDate: 2008-05-29 17:37:14
Subject: Re: Core team statement on replication in PostgreSQL

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