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

Re: Core team statement on replication in PostgreSQL

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Douglas McNaught <doug(at)mcnaught(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, 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 16:19:48
Message-ID: 483ED7A4.50703@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers

Dave Page wrote:
> On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught <doug(at)mcnaught(dot)org> wrote:
>   
>> On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>>
>>     
>>> The only question I have is... what does this give us that PITR doesn't
>>> give us?
>>>       
>> I think the idea is that WAL records would be shipped (possibly via
>> socket) and applied as they're generated, rather than on a
>> file-by-file basis.  At least that's what "real-time" implies to me...
>>     
>
> Yes, we're talking real-time streaming (synchronous) log shipping.
>   

That's not what Tom's email said, AIUI. "Synchronous" replication surely 
means that the master and slave always have the same set of transactions 
applied. Streaming <> synchronous. But streaming log shipping will allow 
us to get get closer to synchronicity in some situations, i.e. the 
window for missing transactions will be much smaller.

Some of us were discussing this late on Friday night after PGcon. ISTM 
that we can have either 1) fairly hot failover slaves that are 
guaranteed to be almost up to date, or 2) slaves that can support 
read-only transactions but might get somewhat out of date if they run 
long transactions. The big problem is in having slaves which are both 
highly up to date and support arbitrary read-only transactions. Maybe in 
the first instance, at least, we need to make slaves choose which role 
they will play.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Marko KreenDate: 2008-05-29 16:20:37
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Josh BerkusDate: 2008-05-29 16:18:44
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Marko KreenDate: 2008-05-29 16:20:37
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Josh BerkusDate: 2008-05-29 16:18:44
Subject: Re: Core team statement on replication in PostgreSQL

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