Re: head fails to build on SLES 12 (wal_compression=zstd) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: head fails to build on SLES 12 (wal_compression=zstd)
Date
Msg-id 906345.1648775400@sss.pgh.pa.us
Whole thread Raw
In response to Re: head fails to build on SLES 12 (wal_compression=zstd)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: head fails to build on SLES 12 (wal_compression=zstd)
Re: head fails to build on SLES 12 (wal_compression=zstd)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 31, 2022 at 7:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Indeed.  I tried building against 1.3.6 (mainly because it was laying
>> around) and the error reported by Devrim is just the tip of the iceberg.
>> ...
>> I wonder whether Robert's ambition to be compatible with old versions
>> extends that far.

> It definitely doesn't, and the fact that there's that much difference
> in the APIs between 2018 and the present frankly makes my heart sink.

AFAICS it's just additions; this stuff is not evidence that they
broke anything.

> It looks like this stuff may be what libzstd calls the "advanced API"
> which was considered unstable until 1.4.0 according to
> https://github.com/facebook/zstd/releases -- so maybe we ought to
> declare anything pre-1.4.0. to be unsupported.

That seems like the appropriate answer to me.  I verified that we
build cleanly and pass check-world against 1.4.0, and later I'm
going to set up BF member longfin to use that.  So that will give
us an anchor that we support zstd that far back.  Had we written
this code earlier, maybe we'd have confined ourselves to 1.3.x
features ... but we didn't, and I don't see much value in doing
so now.

In short, I think we should push Justin's version-check patch,
and also fix the SGML docs to say that we require zstd >= 1.4.0.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: unlogged sequences
Next
From: "David G. Johnston"
Date:
Subject: Re: unlogged sequences