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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-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

Browse pgsql-advocacy by date

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

Browse pgsql-hackers by date

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