On Thu, Mar 31, 2022 at 12:26:46PM -0400, Robert Haas wrote: > On Thu, Mar 31, 2022 at 11:44 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Justin Pryzby <pry...@telsasoft.com> writes: > > > Possible responses look like: > > > - Use 0 which also means "default" (need to verify that works across > > > versions); > > > - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3; > > > - Add a test for a minimum zstd version v1.3.7. This may be a good idea > > > for > > > v15 in any case, since we're using a few different APIs (at least > > > ZSTD_compress and ZSTD_compressStream2 and execve(zstd)). > > > > In view of 51c0d186d ("Allow parallel zstd compression"), I agree > > that some clarity about the minimum supported version of zstd > > seems essential. I don't want to be dealing with threading bugs > > in ancient zstd versions. However, why do you suggest 1.3.7 in > > particular? > > One thing to note is that apparently threading wasn't enabled in the > default build before 1.5.0, which was released in May 2021, but it did > exist as an option in the code for some period of time prior to that. > I don't know how long exactly. I don't want to jump to the conclusion > that other people's old versions are full of bugs, but if that should > happen to be true here, there's some chance that PostgreSQL users > won't be exposed to them just because threading wasn't enabled by > default until quite recently.
Right. Importantly, it's a run-time failure condition if threading wasn't enabled at compile time. Postgres should still compile --with-zstd even if it wasn't, and pg_basebackup should work, except if workers is specified (or maybe if workers>0, but it's possible that allowing workers=0 wasn't true before some version). I'll write more later. -- Justin