Re: head fails to build on SLES 12 (wal_compression=zstd)

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