From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Devrim Gündüz <devrim(at)gunduz(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: head fails to build on SLES 12 (wal_compression=zstd) |
Date: | 2022-04-01 00:39:28 |
Message-ID: | CA+TgmoYFUqutjSet6tLaVamBWrR6ZCf4zMAPbBwncY-DgDfRZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 31, 2022 at 7:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-04-01 00:42:29 | Re: unlogged sequences |
Previous Message | Robert Haas | 2022-04-01 00:30:54 | Re: should vacuum's first heap pass be read-only? |