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
