I added s390x manually from apt, if that doesn't work I can remove it

Did you update this viaversions.sh or by hand?

Templates should be linted

• LegacyKeyValueFormat linter is noisy with very little practical value moby/buildkit#5130

Were there any problems with alpine 3.22?
It features LLVM 20, but the template downgrades to 19.

We've been pinned to LLVM 19 for all versions where we could for quite a while, so we just didn't change that. I went looking for a "recommended LLVM version" from upstream, and wasn't able to find one; the best I found washttps://www.postgresql.org/docs/18/install-make.html#CONFIGURE-WITH-LLVM

The minimum required version of LLVM is currently 14.

(and that minimum is lower on other versions)

My understanding of LLVM compatibility is that thereare often compatibility issues when using newer versions (and that's part of why Debian's struggled so much with LLVM versions for the Trixie release, for example, and the fact that Alpine has so many versions in this latest release:https://pkgs.alpinelinux.org/packages?name=llvm%5B0-9%5D%5B0-9%5D&branch=v3.22&arch=x86_64 - all of 15-20), so I'd be hesitant to bump this withoutsome evidence that it's probably fine to do so.

I added s390x manually from apt, if that doesn't work I can remove it

Did you update this viaversions.sh or by hand?

After update/versions.sh created the 18 entry, I double-checked the repo and added s390x manually, as I wrote.

See

I removed s390x.

After some digging, the test failure is fromthis line:

++ echo 'SET jit = on; SELECT pg_jit_available();'++ psql++ docker run --rm -i --link postgres-container-2708-10581:postgres --entrypoint psql -e 'PGPASSWORD=my cool postgres password' postgres:18-test --host postgres --username 'my cool postgres user' --dbname 'my cool postgres database' --quiet --no-align --tuples-only+ '[' f = t ']'

And the "problem" is thatjit for PostgreSQL is aseparate package for 18.

+ apt-get install -y --no-install-recommends postgresql-18=18~beta1-1.pgdg120+1...Recommended packages:  krb5-locales ca-certificates postgresql-18-jit sysstat

So, we can either change the test to skip it for 18 or install thepostgresql-18-jit package which is not a small add. The largejit size is already in the current images but this is a new major, so it could change and let users have smaller images. On upstream-built architectures, it would be as easy asapt-get install, but it would not be so easy to add for users on architectures where we build usingdeb-src (i.e. arches that aren'tamd64,arm64, orppc64el).

$docker run -it --rm postgres:18-test bashroot@d80424019501:/#apt update...root@d80424019501:/#apt install postgresql-18-jit...The following additional packages will be installed:  libbsd0 libedit2 libllvm19 libz3-4The following NEW packages will be installed:  libbsd0 libedit2 libllvm19 libz3-4 postgresql-18-jit0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded.Need to get 43.2 MB of archives.After this operation, 178 MB of additional disk space will be used.

My vote is to not includejit in 18, and direct users to extend the image and installpostgresql-18-jit for their use. But I am fine either way.

I created a test fallback, on Alpine or if postgresql-18-jit has been installed thenpg_jit_available() = 't' works.
docker-library/official-images#19179

But this has to be documented, many users will expect a "full" Postgres image.
So the Debian images should be split:18-bookworm (new official image without JIT) and18-bookworm-jit.

Yeah, I'm not sure how we should handle this totally yet, but I think I'm pretty sold on the "default" variants being JIT-enabled. The appropriate question is probably whether "no-JIT" is useful enough to actually offer an alternative tag for, and what wrench the promise of future extensionsalso being extracted from the core throws in any tag naming convention we come up with. (All this especially when the "non-JIT" variants are very nearly the same size as the JIT-enabled Alpine variants.)

For now, I think we should probably just continue to include JIT and we can consider non-JIT orthogonally.

I like JIT by default better too, inverted the last commit.
This makes all images the same (Alpine and Debian are JIT-enabled, just like postgres:17).

Rebased to update template instead of build time detection

For the JIT issue, would it be possible to have an environmental variable, something likeINSTALL_JIT (probably set to true by default), and in the startup script you could check the flag and whetherpostgresql-18-jit is installed, and if the flag is enabled and the package not yet installed, install it then and there just in time (hehe). This way, there would be no need for separate images and the user could skip the extra package if they wish for it, or they could include it at the expense of delayed first time startup (since the package needs to be downloaded and isntalled). The only real issue is if the container has no internet access to download the package.

Build time dynamism has already been removed by reviewers and you want to introduce runtime dynamism to it?
Never heard of a Docker image doing that and I don't see the advantage.
If a user want's no JIT, a corresponding image should be chosen instead of a runtime variable installing / uninstalling packages.
With my solution those 2 images could've been built just by adding a build arg.
But as I can't really imagine anyone running a database not wanting better performance, I think JIT by default is preferable to saving disk space.
And if someone would care about disk space more than the less flexible Alpine images are much smaller anyway even with JIT included.

@reneleonhardt First of all, I have a few containers where I override the entrypoint to do some extra configurations, instead of creating a whole new image based on it, so it can be done, for what it's worth. Secondly, I too think JIT should be enabled and don't see a reason to exclude it, but you can always find someone that will think otherwise. Thirdly, I was just giving some ideas, whether it's a good one or a bad one is up to them to decide. Thirdly,