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 1obA8D-0007wS-IT for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2022 00:31:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1obA8C-0005IZ-4t for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2022 00:31:56 +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 1obA8B-0005IN-Mc for pgsql-hackers@lists.postgresql.org; Thu, 22 Sep 2022 00:31:55 +0000 Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1obA87-0007Ts-IG for pgsql-hackers@lists.postgresql.org; Thu, 22 Sep 2022 00:31:54 +0000 Received: by mail-io1-xd2f.google.com with SMTP id d8so6466877iof.11 for ; Wed, 21 Sep 2022 17:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=kg8Xl5Z6EBH0U3daWZYV+X5u8vPNI0Lw1H+4Asox3IA=; b=YW/WR6JBSG3Gsixnw4dfpKvoQfLuWtAXkxauw9KE3jFUnUpRt7GBvzWId/xnWELHqf RhEVg1LWbWtUYXLi0WpcUQWgBmbTcc0yYyMQ+FJTysGoW3VgeCoaJZTj4qpKeon/2VBo sbxRWKKQJO1maC2M/p0Z/qlRPteyOeRDXkmQkW6nreS7aTJA20k6E8EW30y6Ci2x3fig LUbAGeLa+NVXvjpZebqUhLKk4ue0Yho8pooITC0ZYpe11xhivnAKLGdbqHYCwcRRRqXJ 28n3JmorML5xuTDHt6850+y7jJqjvIKSaKZY2DDw6HAHvCevAwKuBx/X1nEXmtn9VmCq 7gug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=kg8Xl5Z6EBH0U3daWZYV+X5u8vPNI0Lw1H+4Asox3IA=; b=Nz/xUpCc0MTR6hSU4kH+a4cBt2XaNMKB85nlp7VR7vTqKEbUaIlZxoBIOKI1cEnRnZ 9ggH4n3enoBxPQXfZkzGSRz5UQuJPuJTq6Hg1JxwBc7om3wsir4penXr8TqqJOdxMiLX S2lDeaL8XdMuTtE8vJvEEgbzPQRPnjcBsYT/amGRTlkTeF9kg97JQzXC0S1UhWJI9a1D mJE8BzlG14BMQv0lmLOAF69trgxRsomUo6bBQYUBJZk5gSM+G7ocBOKDR1v+2aBe5nGc uZf9GYnePQAGbuW8O/l9plquphnrnmVCUVcskK4hU0/RQ6kveawuiDsO7xBKqrK8ukf1 ePeA== X-Gm-Message-State: ACrzQf0giB4op4/qSQ+EnqjRNKUk2mPabcrZ9wdIcAfkQ3ME14IjuPN1 8VAMACC7UFvQprlitXHri87D7bVqMIIlJg== X-Google-Smtp-Source: AMsMyM4dpUTD48Q4mf5+Knx9DIKNhNsoCnGWNnquhnIYFeDmubG9pzobE29KI1wGjzBaA9g9E3o+MQ== X-Received: by 2002:a05:6638:2402:b0:35a:1e83:e43b with SMTP id z2-20020a056638240200b0035a1e83e43bmr519252jat.146.1663806710005; Wed, 21 Sep 2022 17:31:50 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id bm4-20020a05663842c400b0034294118e1bsm1611072jab.126.2022.09.21.17.31.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Sep 2022 17:31:49 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 4BE7C800CA7; Wed, 21 Sep 2022 19:31:48 -0500 (CDT) Date: Wed, 21 Sep 2022 19:31:48 -0500 From: Justin Pryzby To: Michael Paquier Cc: Tom Lane , pgsql-hackers@lists.postgresql.org Subject: Re: pg_basebackup's --gzip switch misbehaves Message-ID: <20220922003148.GK31833@telsasoft.com> References: <1400032.1662217889@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 13, 2022 at 04:13:20PM +0900, Michael Paquier wrote: > diff --git a/src/common/compression.c b/src/common/compression.c > index da3c291c0f..ac26287d54 100644 > --- a/src/common/compression.c > +++ b/src/common/compression.c > @@ -249,36 +299,49 @@ expect_integer_value(char *keyword, char *value, pg_compress_specification *resu > char * > validate_compress_specification(pg_compress_specification *spec) > { > + int min_level = 1; > + int max_level = 1; > + int default_level = 0; > + > /* If it didn't even parse OK, it's definitely no good. */ > if (spec->parse_error != NULL) > return spec->parse_error; > > /* > - * If a compression level was specified, check that the algorithm expects > - * a compression level and that the level is within the legal range for > - * the algorithm. > + * Check that the algorithm expects a compression level and it is > + * is within the legal range for the algorithm. > */ > - if ((spec->options & PG_COMPRESSION_OPTION_LEVEL) != 0) > + switch (spec->algorithm) > { > - int min_level = 1; > - int max_level; > - > - if (spec->algorithm == PG_COMPRESSION_GZIP) > + case PG_COMPRESSION_GZIP: > max_level = 9; > - else if (spec->algorithm == PG_COMPRESSION_LZ4) > +#ifdef HAVE_LIBZ > + default_level = Z_DEFAULT_COMPRESSION; > +#endif > + break; > + case PG_COMPRESSION_LZ4: > max_level = 12; > - else if (spec->algorithm == PG_COMPRESSION_ZSTD) > + default_level = 0; /* fast mode */ > + break; > + case PG_COMPRESSION_ZSTD: > max_level = 22; I should've suggested to add: > min_level = -7; which has been supported since zstd 1.3.4 (and postgres requires 1.4.0). I think at some point (maybe before releasing 1.3.4) the range was increased to very large(small), negative levels. It's possible to query the library about the lowest supported compression level, but then there's a complication regarding the client-side library version vs the server-side version. So it seems better to just use -7. -- Justin