The bounds hardcoded in compression.c since
ffd5365 (minimum at 1 and
maximum at 22) do not match the reality of what zstd is able to
handle, these values being available via ZSTD_maxCLevel() and
ZSTD_minCLevel() at run-time. The maximum of 22 is actually correct
in recent versions, but the minimum was not as the library can go down
to -131720 by design. This commit changes the code to use the run-time
values in the code instead of some hardcoded ones.
Zstd seems to assume that these bounds could change in the future, and
Postgres will be able to adapt automatically to such changes thanks to
what's being done in this commit.
Reported-by: Justin Prysby
Discussion: https://postgr.es/m/
20220922033716.GL31833@telsasoft.com
Backpatch-through: 15
<literal>-1</literal>), for <literal>lz4</literal> an integer
between 1 and 12 (default <literal>0</literal> for fast compression
mode), and for <literal>zstd</literal> an integer between
- <literal>1</literal> and <literal>22</literal> (default
- <literal>ZSTD_CLEVEL_DEFAULT</literal> or <literal>3</literal>).
+ <literal>ZSTD_minCLevel()</literal> (usually <literal>-131072</literal>)
+ and <literal>ZSTD_maxCLevel()</literal> (usually <literal>22</literal>),
+ (default <literal>ZSTD_CLEVEL_DEFAULT</literal> or
+ <literal>3</literal>).
</para>
<para>
default_level = 0; /* fast mode */
break;
case PG_COMPRESSION_ZSTD:
- max_level = 22;
#ifdef USE_ZSTD
+ max_level = ZSTD_maxCLevel();
+ min_level = ZSTD_minCLevel();
default_level = ZSTD_CLEVEL_DEFAULT;
#endif
break;