Philip Warner <pjw@rhyme.com.au> writes:
>> Not bloody likely! Do you want to be in a position where you restart
>> your postmaster and suddenly chunks of your database are inaccessible?
>> That's what could happen to you if someone moves or deletes libz.so.
> My question was limited to it's use in pg_dump; rather than basing
> pg_dump's compression bahaviour on configure, base it on it's runtime
> environment. But my guess is you still would be inclined, rather strongly,
> against it.
pg_dump is rather a different case. I would want to see a runtime
option *not* to use compression, in case you know you are going to
need to restore on another system where zlib (or whatever) isn't
available. But making an uncompressed dump today doesn't invalidate
the compressed dump you made yesterday, nor vice versa.
>> If we do go with using zlib instead of homegrown code
> This begs the obvious question: should pg_dump be using Jan's compression
> code? In all cases/when zlib is not available?
Good point. If we include zlib in the distribution it would be pretty
silly for pg_dump not to use it. If we don't, then Peter's remarks
about not liking an environment-determined feature set are relevant.
regards, tom lane