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 1oYKmn-0001Co-Sn for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 05:18:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oYKmm-0000xF-IH for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 05:18:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYKmm-0000x6-9H for pgsql-hackers@lists.postgresql.org; Wed, 14 Sep 2022 05:18:08 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYKmj-0003J3-Kl for pgsql-hackers@lists.postgresql.org; Wed, 14 Sep 2022 05:18:07 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 28E5I3JW2529395; Wed, 14 Sep 2022 01:18:03 -0400 From: Tom Lane To: Michael Paquier cc: pgsql-hackers@lists.postgresql.org Subject: Re: pg_basebackup's --gzip switch misbehaves In-reply-to: References: <1400032.1662217889@sss.pgh.pa.us> <2402847.1663105127@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Wed, 14 Sep 2022 13:59:01 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2529393.1663132683.1@sss.pgh.pa.us> Date: Wed, 14 Sep 2022 01:18:03 -0400 Message-ID: <2529394.1663132683@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > And so, I have spent a couple of hours torturing the patch, applying > it after a few tweaks and CI runs: > ... > The buildfarm is green so I think that we are good. I have closed the > open item. +1, thanks for taking care of that. As far as my original complaint about mamba goes, I've not quite been able to run it to ground. However, I found that NetBSD seems to be shipping unmodified zlib 1.2.11, which contains a number of known bugs in deflate_stored() --- that is, the code path implementing compression level 0. Red Hat for one is carrying several back-patched fixes in that part of zlib. So for the moment I'm willing to write it off as "not our bug". We aren't intentionally testing compression level 0, and hardly anybody would intentionally use it in the field, so it's not really a thing worth worrying about IMO. But if mamba continues to show failures in that test then it will be worth looking closer. regards, tom lane