Andreas Pflug <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly