Subject: head fails to build on SLES 12

From: Devrim Gündüz <[email-masked]>
Date: Thu, 31 Mar 2022 15:23:22 +0100

Hi,

Latest snapshot tarball fails to build on SLES 12.5, which uses GCC
4.8-8. Build log is attached.

Please let me know if you want me to provide more info.

Thanks!

Regards,
-- 
Devrim Gündüz
Open Source Solution Architect, PostgreSQL guy
Twitter: @DevrimGunduz , @DevrimGunduzTR

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Mar 2022 10:26:31 -0400

> 4.8-8. Build log is attached.

Hmm, what version of libzstd is present?

			regards, tom lane

---

From: Devrim Gündüz <[email-masked]>
Date: Thu, 31 Mar 2022 15:38:39 +0100

Hi,

> Hmm, what version of libzstd is present?

1.3.3

Regards,
-- 
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 31 Mar 2022 10:37:40 -0500

> > Hmm, what version of libzstd is present?

That's due to commit e9537321a74a2b062c8f7a452314b4570913f780.

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)).

I dug up this history:

commit b2632bcf6cf7b9b96e0ac99beea079df4d1eaec5
Merge: 170f948e 869e2718
Author: Yann Collet <[email-masked]>
Date:   Tue Jun 12 12:09:01 2018 -0700

    Merge pull request #1174 from duc0/document_default_level
    
    Expose ZSTD_CLEVEL_DEFAULT and update documentation

commit e34c000e44444b9f8bd62e5af0a355ee186eb21f
Author: Duc Ngo <[email-masked]>
Date:   Fri Jun 8 11:29:51 2018 -0700

    Expose ZSTD_CLEVEL_DEFAULT and update documentation

commit 6d4fef36de21908e333b2a1fde8ded0a7f086ae1
Author: Yann Collet <[email-masked]>
Date:   Wed May 17 18:36:15 2017 -0700

    Added ZSTD_compress_generic()

    Used in fileio.c (zstd cli).
    Need to set macro ZSTD_NEWAPI to trigger it.

commit 236d94fa9a4ff8723922971274a119c6084d5dbc
Author: Yann Collet <[email-masked]>
Date:   Wed May 18 12:06:33 2016 +0200

    reverted default compression level to 1

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Mar 2022 11:44:40 -0400

>    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?

			regards, tom lane

---

From: Robert Haas <[email-masked]>
Date: Thu, 31 Mar 2022 12:26:46 -0400

> in ancient zstd versions.  However, why do you suggest 1.3.7 in

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.

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

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 31 Mar 2022 11:34:41 -0500

> 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

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Mar 2022 12:37:18 -0400

> default until quite recently.

Hm.  After rereading 51c0d186d I see that we're not asking for
parallel compression unless the user tells us to, so I guess
our fallback answer for any complaints in that area can be
"if it hurts, don't do it".  Still, I like the idea of having
a well-defined minimum zstd version that we consider supported.
The evident fact that their APIs are still changing (or at
least have done so within the memory of LTS platforms) makes
that fairly pressing.  Question is what to set the minimum to.

			regards, tom lane

---

From: Robert Haas <[email-masked]>
Date: Thu, 31 Mar 2022 12:55:18 -0400

On Thu, Mar 31, 2022 at 12:37 PM Tom Lane <[email-masked]> wrote:
> "if it hurts, don't do it".

Right. We can also tell people that if they are running buggy versions
of libzstd or liblz4 or libz, they should upgrade to non-buggy
versions. Our ability to paper over bugs in compression libraries is
going to be extremely limited.

> Still, I like the idea of having

I think we should aim, if we can, to be compatible with libzstd
versions that are still being shipped with still-supported releases of
mainstream Linux distributions. If that turns out to be too hard, we
can be less ambitious.

On the particular question of ZSTD_CLEVEL_DEFAULT, it does not seem
likely that the library would have only recently exposed a symbol that
is required for correct use of the API, so I bet there's a relatively
simple way to avoid needing that altogether (perhaps by writing "0"
instead).

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 31 Mar 2022 15:58:34 -0400

> Please let me know if you want me to provide more info.

AFAICT we don't have any buildfarm animals currently reporting on SLES
12 (and the one we did have was on s390x, if that matters).

So if this is something that needs support we should address that. After
all, that's exactly what the buildfarm was created for.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Larry Rosenman <[email-masked]>
Date: Thu, 31 Mar 2022 15:03:50 -0500

> all, that's exactly what the buildfarm was created for.

I can spin up a VM on SLES 12 assuming someone can point me to the right 
place to get
an ISO, etc, and I don't need a payfor license.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: [email-masked]
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 31 Mar 2022 17:42:30 -0500

> in ancient zstd versions.  However, why do you suggest 1.3.7 in

That's where I found that ZSTD_CLEVEL_DEFAULT was added, in their git.

I've just installed a .deb for 1.3.8, and discovered that the APIs used by
basebackup were considered experimental/nonpublic/static-lib-only until 1.4.0
https://github.com/facebook/zstd/releases/tag/v1.4.0
ZSTD_CCtx_setParameter ZSTD_c_compressionLevel ZSTD_c_nbWorkers ZSTD_CCtx_reset ZSTD_reset_session_only ZSTD_compressStream2 ZSTD_e_continue ZSTD_e_end

FYI: it looks like parallel, thread workers were also a nonpublic,
"experimental" API until v1.3.7.  Actually, ZSTD_p_nbThreads was renamed to
ZSTD_p_nbWorkers and then (in 1.3.8) renamed to ZSTD_c_nbWorkers.

Versions less than 1.3.8 would have required compile-time conditionals for both
ZSTD_CLEVEL_DEFAULT and ZSTD_p_nbThreads/ZSTD_p_nbWorkers/ZSTD_c_nbWorkers (but
that is moot).

Negative compression levels were added in 1.3.4 (but I think the range of their
levels was originally -1..-7 and now expanded).  And long-distance matching
added in 1.3.2.

cirrus has installed:
linux (debian bullseye) 1.4.8
macos has 1.5.0
freebsd has 1.5.0

debian buster (oldstable) has v1.3.8, which is too old.
ubuntu focal LTS has 1.4.4 (bionic LTS has 1.3.3 which seems too old)
rhel7 has 1.5.2 in EPEL;

SLES 12.5 has zstd 1.3.3, so it won't be supported.  But postgres should fail
gracefully during ./configure rather than during build.

Note that check-world fails if wal_compression is enabled due to two
outstanding issues, so it's not currently possible to set that in CI or
buildfarm...
https://www.postgresql.org/message-id/c86ce84f-dd38-9951-102f-13a931210f52%40dunslane.net

---

From: Tom Lane <[email-masked]>
Date: Thu, 31 Mar 2022 19:38:29 -0400

> basebackup were considered experimental/nonpublic/static-lib-only until 1.4.0

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.

			regards, tom lane