Tom Lane wrote:
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.
Um, as long as xlog writing stops immediate recycling when
pg_start_backup is executed everything should be fine, since archived
logs are not expected to be present until pg_stop_backup is done.
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.
I certainly have an extreme cornercase, since data is highly
compressible. I won't suggest to replace pg_dump by physical backup
methods, but disaster recovery may take considerably longer from a dump
than from filesystem level backup.
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.
I'd really love a copy format that works for binary and text data as
well, optimally compressed. Initial replication to a new slony cluster
node uses COPY, and network bandwidth may become the restricting factor.
Line protocol compression would be desirable for that too, but that's
another story.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
