Re: XLogArchivingActive

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