On Thu, Mar 31, 2022 at 12:37 PM Tom Lane <t...@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
