Re: XLogArchivingActive

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> That's right, but my proposal would implicitely switch on archiving 
> while backup is in progress, thus explicitely enabling/disabling 
> archiving wouldn't be necessary.

I'm not sure you can expect that to work.  The system is not built to
guarantee instantaneous response to mode changes like that.

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

The conventional wisdom is that pg_dump files are substantially smaller
than the on-disk footprint ... and that's even without compressing them.
I think you are taking a corner case, ie bytea data, and presenting it
as something that ought to be the design center.

Something that might be worth considering is an option to allow pg_dump
to use binary COPY.  I don't think this'd work nicely for text dumps,
but seems like custom- or tar-format dumps could be made to use it.
This would probably be a win for many datatypes not only bytea, and it'd
still be far more portable than a filesystem dump.
        regards, tom lane