[Justin Pryzby <pryzby@telsasoft.com>]

On Thu, Sep 22, 2022 at 10:25:11AM +0900, Michael Paquier wrote:
> 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.

Okay.  Will that complicate tests at all?  It looks like it's not an
issue for the tests currently proposed in the CF APP.
https://commitfest.postgresql.org/39/3835/

However the patch ends up, +0.75 to backpatch it to v15 rather than
calling it a new feature in v16.

-- 
Justin