>>> On Mon, Jun 9, 2008 at 9:48 PM, in message
<Pine(dot)GSO(dot)4(dot)64(dot)0806092243080(dot)11286(at)westnet(dot)com>, Greg Smith
<gsmith(at)gregsmith(dot)com> wrote:
> 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.
We ship the WAL files over a (relatively) slow WAN for disaster
recovery purposes, and we would be fine with replacing our current
techniques with real-time log shipping as long as:
(1) We can do it asynchronously. (i.e., we don't have to wait for
WAN latency to commit transactions.)
(2) It can ship to multiple targets. (Management dictates that we
have backups at the site of origin as well as our central site. A
failure to replicate to one must not delay the other.)
(3) It doesn't consume substantially more WAN bandwidth overall.
A solution which fails to cover any of these leaves pg_clearxlogtail
interesting to us.
-Kevin