Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nDOm1-00026c-Ra for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jan 2022 10:46:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nDOlU-0006WT-2S for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jan 2022 10:46:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nDOlT-0006WF-9z for pgsql-hackers@lists.postgresql.org; Fri, 28 Jan 2022 10:45:59 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nDOlN-0005LE-RQ for pgsql-hackers@postgresql.org; Fri, 28 Jan 2022 10:45:57 +0000 Received: by mail-wr1-x435.google.com with SMTP id l25so9985757wrb.13 for ; Fri, 28 Jan 2022 02:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uNK1I7XNqkisRt8s6XULKIfpqXrSfaRBz73sgqMSLc0=; b=L7Y3F9QL0so7ZEhSDeHImrhkBK+caEwSrcxaKnzWwb1kMx7MfMa8evMo7YUc0FPVwZ dFBd7pnVdG4ESuHfFIzK3pJETsst9gNAYb6r+a5Nx//b0ibleR4OsQDXH9ECVLnSIM9W cG67UnZA+fLWH+Rb+2Wj2JKOPZd6XVAUtEzsmRcf6bkBwKz7riK7ncrUnF8mrekXk9jk M0vE/hgLGJ58rk/mQwbAqtsS/X9Pl7PHfRauHR63r8VOovXAOTlkh/fS1J3kqwNOrAGq kTpWAkF2RAoy9bYKDCM201zRHhFpmjWok9pp7z8W5xnHQL8E9JXfDbC0JdEqi9o76mvY oe5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=uNK1I7XNqkisRt8s6XULKIfpqXrSfaRBz73sgqMSLc0=; b=UH+yu7DYPty9BhPbWBaO/arXuN22Qb3htXZ0Rlc0ofje6Pl2kUMaJDi1cYMMAxcZvP tOrcMdgoCbA7SBvSYd4897WXCP2GVHL58Rw8IgRCjcLFg10k6QcUriXGER77Y3xbio64 s/FLX4eHtf6kebW1zqIkBFitN4rQaKhZOMNgJoNHQ9fFd0iNsvS6+f5SyVy4aTlS3JxT uX2C0/PvW+ZB2xXD7qPrIcszBwtmBToDV9tPZhedw3vJzuey5/saUbcvEgBjLbriLAa8 zc1zMKLdo/uB0FE07FOQ5MyV0f9uT18xpKEyokKQtst32tgrZLhZewIx2h7PKcIBnByA maHQ== X-Gm-Message-State: AOAM533cUr2KgassxjRAk1/R2hu3i9QC4Su6nA9ahFs3FHkla0Fsu6E2 JkMkjZ+o/OqaTKreIgvpMbn67wkRDZM0cP4utAScN0CT1JrptdXxe/r9cGrTErMOnyI7OVEcl7D x40+ct38B0jiP+NgLb+riIWxjIrNewg1zmd4QjO2vcOD+bjcOqrh33D/Lh3fB84gDn9eSiaCCjL /A3jB9b0ez0tYTptIghd4R/KN1khSZWVbHe9KRNierJ4zMo/LwED8e6DtMXI54zeVDlnlYs7s8r M2Gjn88qcXWRfaUkZdE55WUecnHIX9RDnuLzA== X-Google-Smtp-Source: ABdhPJxREWGFnkzU/giiUCZ9AVN3D+jqwuaQn6dwabOe/bBYJ9H9wdd3lyPWeJ9UuN3NDiGOCfF9ag== X-Received: by 2002:a05:6000:184a:: with SMTP id c10mr6602430wri.212.1643366750693; Fri, 28 Jan 2022 02:45:50 -0800 (PST) Received: from localhost.localdomain ([45.113.251.168]) by smtp.gmail.com with ESMTPSA id b2sm5271839wrd.64.2022.01.28.02.45.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jan 2022 02:45:50 -0800 (PST) Subject: Re: refactoring basebackup.c To: Robert Haas Cc: Dipesh Pandit , Michael Paquier , Jeevan Ladhe , Dmitry Dolgov <9erthalion6@gmail.com>, Mark Dilger , "pgsql-hackers@postgresql.org" References: <2ed9c215-5d25-04b8-1045-fa30a72085a4@enterprisedb.com> <97b377c3-15b9-517f-1fca-8b4150978e91@enterprisedb.com> From: tushar Message-ID: Date: Fri, 28 Jan 2022 16:15:41 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4CEC260E4F03AEC4B64031B3" Content-Language: en-US X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------4CEC260E4F03AEC4B64031B3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/27/22 11:12 PM, Robert Haas wrote: > Well what's weird here is that you are using both --gzip and also > --compress. Those both control the same behavior, so it's a surprising > idea to specify both. But I guess if someone does, we should make the > second one fully override the first one. Here's a patch to try to do > that. right, the current behavior was  - [edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/y101 --gzip -Z none  -Xnone pg_basebackup: error: cannot use compression level with method none Try "pg_basebackup --help" for more information. and even this was not matching with PG v14 behavior too e.g  ./pg_basebackup -Ft -z -Z none  -D /tmp/test1  ( working in PG v14 but throwing above error on PG HEAD) and somewhere we were breaking the backward compatibility. now with your patch -this seems working fine [edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/y101 --gzip*-Z none*  -Xnone NOTICE:  WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup [edb@centos7tushar bin]$ ls /tmp/y101 backup_manifest *base.tar* OR [edb@centos7tushar bin]$  ./pg_basebackup  -t server:/tmp/y0p -Z none  -Xfetch *-z* [edb@centos7tushar bin]$ ls /tmp/y0p backup_manifest *base.tar.gz* but what about server-gzip:0? should it allow compressing the directory? [edb@centos7tushar bin]$  ./pg_basebackup  -t server:/tmp/1 --compress=server-gzip:0  -Xfetch [edb@centos7tushar bin]$ ls /tmp/1 backup_manifest  base.tar.gz -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company --------------4CEC260E4F03AEC4B64031B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/27/22 11:12 PM, Robert Haas wrote:
Well what's weird here is that you are using both --gzip and also
--compress. Those both control the same behavior, so it's a surprising
idea to specify both. But I guess if someone does, we should make the
second one fully override the first one. Here's a patch to try to do
that.
right, the current behavior was  -

[edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/y101 --gzip -Z none  -Xnone
pg_basebackup: error: cannot use compression level with method none
Try "pg_basebackup --help" for more information.

and even this was not matching with PG v14 behavior too
e.g
 ./pg_basebackup -Ft -z -Z none  -D /tmp/test1  ( working in PG v14 but throwing above error on PG HEAD)

and somewhere we were breaking the backward compatibility.

now with your patch -this seems working fine

[edb@centos7tushar bin]$ ./pg_basebackup  -t server:/tmp/y101 --gzip -Z none  -Xnone
NOTICE:  WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup
[edb@centos7tushar bin]$ ls /tmp/y101
backup_manifest  base.tar

OR

[edb@centos7tushar bin]$  ./pg_basebackup  -t server:/tmp/y0p -Z none  -Xfetch -z
[edb@centos7tushar bin]$ ls /tmp/y0p
backup_manifest  base.tar.gz

but what about server-gzip:0? should it allow compressing the directory?

[edb@centos7tushar bin]$  ./pg_basebackup  -t server:/tmp/1 --compress=server-gzip:0  -Xfetch
[edb@centos7tushar bin]$ ls /tmp/1
backup_manifest  base.tar.gz

-- 
regards,tushar
EnterpriseDB  https://www.enterprisedb.com/
The Enterprise PostgreSQL Company
--------------4CEC260E4F03AEC4B64031B3--