Re: XLogArchivingActive

Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)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