Re: pg_basebackup cannot compress to STDOUNT - Mailing list pgsql-general

From Adrian Klaver
Subject Re: pg_basebackup cannot compress to STDOUNT
Date
Msg-id b954986c-3c5d-0d6f-2c53-be1ce466f1ec@aklaver.com
Whole thread Raw
In response to Re: pg_basebackup cannot compress to STDOUNT  (Support <admin@e-blokos.com>)
Responses Re: pg_basebackup cannot compress to STDOUNT
List pgsql-general
On 5/8/20 12:31 PM, Support wrote:
> 
> On 5/8/2020 12:18 PM, Adrian Klaver wrote:
>> On 5/8/20 12:14 PM, Support wrote:
>>> Hi,
>>>
>>> Despite of the --help saying that it's possible to gzip to STDOUT and 
>>> pipe it for another process
>>> pg_basebackup fails saying that it's not possible to gzip to STDOUT.
>>
>> 1) Postgres version?
>>
>> 2) Command run?
>>
>> 3) Error reported?
>>
>>>
>>> Who to believe then?
>>>
>>>
> 1) Postgres version?
> 12.2 selt compiled with
> ./configure --with-perl --enable-integer-datetimes --enable-depend 
> --with-pam --with-systemd --enable-nls --with-libxslt --with-libxml 
> --with-llvm --with-python --with-icu --with-gssapi --with-openssl
> 
> 2) Command run?
> ssh postgres@nodeXXX "pg_basebackup -h /run/postgresql -Ft -D- | pigz -c 
> -p2 " | pigz -cd -p2 | tar -xf- -C /usr/local/pgsql/data
> 
> 3) Error reported?
> pg_basebackup: error: cannot stream write-ahead logs in tar mode to stdout

https://www.postgresql.org/docs/12/app-pgbasebackup.html
"t
tar

     Write the output as tar files in the target directory. The main 
data directory will be written to a file named base.tar, and all other 
tablespaces will be named after the tablespace OID.

     If the value - (dash) is specified as target directory, the tar 
contents will be written to standard output, suitable for piping to for 
example gzip. This is only possible if the cluster has no additional 
tablespaces and WAL streaming is not used.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
"

So use -X fetch or X none


> Try "pg_basebackup --help" for more information.
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> 
> Thanks!
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Tory M Blue
Date:
Subject: Re: Memory footprint diff between 9.5 and 12
Next
From: "David G. Johnston"
Date:
Subject: Re: Thoughts on how to avoid a massive integer update.