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

From Robert Haas
Subject Re: head fails to build on SLES 12 (wal_compression=zstd)
Date
Msg-id CA+TgmoYFUqutjSet6tLaVamBWrR6ZCf4zMAPbBwncY-DgDfRZQ@mail.gmail.com
Whole thread Raw
In response to Re: head fails to build on SLES 12 (wal_compression=zstd)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: head fails to build on SLES 12 (wal_compression=zstd)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.
> With "make -k", I see unknown-symbol failures on
>
> ZSTD_CCtx_setParameter
> ZSTD_c_compressionLevel
> ZSTD_c_nbWorkers
> ZSTD_CCtx_reset
> ZSTD_reset_session_only
> ZSTD_compressStream2
> ZSTD_e_continue
> ZSTD_e_end
>
> 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.

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. I really hope they're
serious about keeping the advanced API stable, though. I'm excited
about the potential of using libzstd, but I don't want to have to keep
adjusting our code to work with new library versions.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: should vacuum's first heap pass be read-only?
Next
From: Tomas Vondra
Date:
Subject: Re: unlogged sequences