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: 2006-05-25 21:53:56
Message-ID: F6309784-C614-4730-B045-B7BD40EC1E56@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-05-25 21:54:38 Re: Gborg and pgfoundry
Previous Message Marc G. Fournier 2006-05-25 20:59:05 Re: Gborg and pgfoundry