Re: Core team statement on replication in PostgreSQL

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Andreas 'ads' Scherbaum" <adsmail(at)wars-nicht(dot)de>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-06-10 09:43:51
Message-ID: 87y75dmxpk.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

"Greg Smith" <gsmith(at)gregsmith(dot)com> writes:

> On Mon, 9 Jun 2008, Tom Lane wrote:
>
>> It should also be pointed out that the whole thing becomes uninteresting
>> if we get real-time log shipping implemented. So I see absolutely no
>> point in spending time integrating pg_clearxlogtail now.
>
> There are remote replication scenarios over a WAN (mainly aimed at disaster
> recovery) that want to keep a fairly updated database without putting too much
> traffic over the link. People in that category really want zeroed
> tail+compressed archives, but probably not the extra overhead that comes with
> shipping smaller packets in a real-time implementation.

Instead of zeroing bytes and depending on compression why not just pass an
extra parameter to the archive command with the offset to the logical end of
data. The archive_command could just copy from the start to that point and not
bother transferring the rest.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Heikki Linnakangas 2008-06-10 10:03:08 Re: Core team statement on replication in PostgreSQL
Previous Message Santiago Zarate 2008-06-10 06:22:38 POP material

Browse pgsql-hackers by date

  From Date Subject
Next Message 汪琦 2008-06-10 09:50:03 why copy tuple in the end of trigger when nothing changed in NEW, OLD record variable
Previous Message Mark Cave-Ayland 2008-06-10 09:16:51 Re: Strange issue with GiST index scan taking far too long