Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

From Steve Atkins
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 4AE4C6AA-6F0C-4289-8F16-CFF46ED20DA0@blighty.com
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  (David Fetter <david@fetter.org>)
Responses Re: Core team statement on replication in PostgreSQL  (Andreas 'ads' Scherbaum <adsmail@wars-nicht.de>)
List pgsql-hackers
On May 29, 2008, at 9:12 AM, David Fetter wrote:

> On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
>> Josh Berkus wrote:
>>> Publishing the XIDs back to the master is one possibility.  We
>>> also looked at using "spillover segments" for vacuumed rows, but
>>> that seemed even less viable.
>>>
>>> I'm also thinking, for *async replication*, that we could simply
>>> halt replication on the slave whenever a transaction passes minxid
>>> on the master.  However, the main focus will be on synchrounous
>>> hot standby.
>>
>> Another idea I discussed with Tom is having the slave _delay_
>> applying WAL files until all slave snapshots are ready.
>
> Either one of these would be great, but something that involves
> machines that stay useless most of the time is just not going to work.

I have customers who are thinking about warm standby functionality, and
the only thing stopping them deploying it is complexity and maintenance,
not the cost of the HA hardware. If trivial-to-deploy replication that  
didn't
offer read-only access of the slaves were available today I'd bet that  
most
of them would be using it.

Read-only slaves would certainly be nice, but (for me) it's making it  
trivial to
deploy and maintain that's more interesting.

Cheers,  Steve



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Core team statement on replication in PostgreSQL
Next
From: Mathias Brossard
Date:
Subject: Re: Core team statement on replication in PostgreSQL