Re: pg_basebackup wish list - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: pg_basebackup wish list
Date
Msg-id CAMkU=1zENYj9H82qc-+aPAEwyFD6LBaUHvuCj1b4ZZ=44muAHQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup wish list  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Jul 28, 2016 at 4:44 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Jul 26, 2016 at 11:58 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Jul 13, 2016 at 3:06 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
>>> On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut
>>> <peter.eisentraut@2ndquadrant.com> wrote:
>>>> On 7/12/16 12:53 PM, Jeff Janes wrote:
>>>>> The --help message for pg_basebackup says:
>>>>>
>>>>> -Z, --compress=0-9     compress tar output with given compression level
>>>>>
>>>>> But -Z0 is then rejected as 'invalid compression level "0"'.  The real
>>>>> docs do say 1-9, only the --help message has this bug.  Trivial patch
>>>>> attached.
>>>>
>>>> pg_dump --help and man page say it supports 0..9.  Maybe we should make
>>>> that more consistent.
>>>
>>> pg_dump actually does support -Z0, though.  Well, sort of.  It outputs
>>> plain text.  Rather than plain text wrapped in some kind of dummy gzip
>>> header, which is what I had naively expected.
>>>
>>> Is that what -Z0 in pg_basebackup should do as well, just output
>>> uncompressed tar data, and not add the ".gz" to the "base.tar" file
>>> name?
>>
>> Yes, I think. What about the attached patch?
>>
>
> What if user tries to use -Z 0 with format as tar, won't it generate
> base.tar without any compression?  I am not sure if that is what Jeff
> intends to say in his proposal.

My initial proposal was just to change the "usage" message to match reality.

I think the current proposal is to make -Z0 be identical to having no
-Z specified at all, in other words produce a .tar file, not a .tar.gz
file.

I had thought we could make a .gz file which didn't actually use
compression, just packaged up the data behind a gzip header, but after
looking at it I don't think libz actually supports that.  Plus, it
would be pretty silly to have uncompressed data that would then have
to be "uncompressed" merely to unwrap it.  It could be useful for
testing where you don't want to write for special cases in your shell
script (which is where I discovered this, I wanted to test all values
between 0 and 9 and see which was fastest given my combination of CPU,
network, data and disks), but not useful for practical use.

I am happy with the code as currently committed.

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: HandleParallelMessages contains CHECK_FOR_INTERRUPTS?
Next
From: Peter Eisentraut
Date:
Subject: Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty()