Tom Lane wrote:
> 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.
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