Re: pg_basebackup's --gzip switch misbehaves

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_basebackup's --gzip switch misbehaves
Date: 2022-09-22 01:25:11
Message-ID: Yyu5d/wUcEaLJje5@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
zstd-minmax-level.patch text/x-diff 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-09-22 01:46:41 Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
Previous Message Tom Lane 2022-09-22 01:12:04 Re: pg_basebackup --create-slot-if-not-exists?