Horton

Re: pg_basebackup's --gzip switch misbehaves

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2022-09-22T01:25:11Z
Lists: pgsql-hackers

Attachments

On Wed, Sep 21, 2022 at 07:31:48PM -0500, Justin Pryzby wrote:
> 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.

Indeed.  Contrary to the default level, there are no variables for the
minimum and maximum levels.  As you are pointing out, a lookup at 
zstd_compress.c shows that we have ZSTD_minCLevel() and
ZSTD_maxCLevel() that assign the bounds.  Both are available since
1.4.0.  We still need a backend-side check as the level passed with a
BASE_BACKUP command would be only validated there.  It seems to me 
that this is going to be less of a headache in the long-term if we
just use those routines at runtime, as zstd wants to keep some freedom
with the min and max bounds for the compression level, at least that's
the flexibility that this gives the library.  So I would tweak things
as the attached.
--
Michael

Commits

  1. Make PG_TEST_NOCLEAN work for temporary directories in TAP tests

  2. doc: document the TAP test environment variables

  3. doc: update metacpan.org links to avoid redirects

  4. Use min/max bounds defined by Zstd for compression level

  5. Fix incorrect value for "strategy" with deflateParams() in walmethods.c

  6. Simplify handling of compression level with compression specifications