>>> On Mon, Jun 9, 2008 at 9:48 PM, in message <[EMAIL PROTECTED]>, Greg Smith <[EMAIL PROTECTED]> 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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers