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
