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