On Thu, Mar 31, 2022 at 12:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm. After rereading 51c0d186d I see that we're not asking for
> parallel compression unless the user tells us to, so I guess
> our fallback answer for any complaints in that area can be
> "if it hurts, don't do it".
Right. We can also tell people that if they are running buggy versions
of libzstd or liblz4 or libz, they should upgrade to non-buggy
versions. Our ability to paper over bugs in compression libraries is
going to be extremely limited.
> Still, I like the idea of having
> a well-defined minimum zstd version that we consider supported.
> The evident fact that their APIs are still changing (or at
> least have done so within the memory of LTS platforms) makes
> that fairly pressing. Question is what to set the minimum to.
I think we should aim, if we can, to be compatible with libzstd
versions that are still being shipped with still-supported releases of
mainstream Linux distributions. If that turns out to be too hard, we
can be less ambitious.
On the particular question of ZSTD_CLEVEL_DEFAULT, it does not seem
likely that the library would have only recently exposed a symbol that
is required for correct use of the API, so I bet there's a relatively
simple way to avoid needing that altogether (perhaps by writing "0"
instead).
--
Robert Haas
EDB: http://www.enterprisedb.com
