On Thu, Mar 31, 2022 at 12:26:46PM -0400, Robert Haas wrote:
> On Thu, Mar 31, 2022 at 11:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Justin Pryzby <pryzby@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
