Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: XLogArchivingActive


  • From: Jim Nasby <jnasby(at)pervasive(dot)com>
  • To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
  • Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
  • Subject: Re: XLogArchivingActive
  • Date: Thu, 25 May 2006 16:53:56 -0500
  • Message-id: <F6309784-C614-4730-B045-B7BD40EC1E56(at)pervasive(dot)com>

On May 25, 2006, at 11:24 AM, Andreas Pflug wrote:
BTW, I don't actually understand why you want this at all.  If you're
not going to keep a continuing series of WAL files, you don't have any PITR capability. What you're proposing seems like a bulky, unportable,
hard-to-use equivalent of pg_dump.  Why not use pg_dump?

Because pg_dump will take too long and create bloated dump files. All I need is a physical backup for disaster recovery purposes without bringing down the server.

In my case, I'd expect a DB that uses 114GB on disk to consume 1.4TB when pg_dumped, too much for the available backup capacity (esp. compared to net content, about 290GB). See other post "inefficient bytea escaping" for details.

Another consideration is that you can use rsync to update a filesystem-level backup, but there's no pg_dump equivalent. On a large database that can make a sizable difference in the amount of time required for a backup.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461





Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group