chore: add postgres 18 beta1

[reneleonhardt]

Updates

• Added Postgres 18 beta1

Notes

• I added s390x manually from apt, if that doesn't work I can remove it
• Templates should be linted

WARN: LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format

Questions

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

[tianon]

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

Did you update this via versions.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 was https://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 there are 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 without some evidence that it's probably fine to do so.

[reneleonhardt]

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

Did you update this via versions.sh or by hand?

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

[tianon]

See

postgres/versions.sh

Lines 116 to 118 in 86e5040

	if [ "$archVersion" = "$suiteVersion" ]; then
	versionArches="$(jq <<<"$versionArches" -c --arg arch "$arch" '. += [$arch]')"
	fi

for the relevant code -- if the exact same version doesn't exist for a given architecture, that's what doesn't include it, so adding s390x manually won't work (it'll fail at build time, not to mention @docker-library-bot immediately reverting that change post-merge).

[reneleonhardt]

I removed s390x.

[yosifkit]

After some digging, the test failure is from this 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 that jit for PostgreSQL is a separate 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 the postgresql-18-jit package which is not a small add. The large jit 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 as apt-get install, but it would not be so easy to add for users on architectures where we build using deb-src (i.e. arches that aren't amd64, arm64, or ppc64el).

$ docker run -it --rm postgres:18-test bash
root@d80424019501:/# apt update
...
root@d80424019501:/# apt install postgresql-18-jit
...
The following additional packages will be installed:
  libbsd0 libedit2 libllvm19 libz3-4
The following NEW packages will be installed:
  libbsd0 libedit2 libllvm19 libz3-4 postgresql-18-jit
0 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 include jit in 18, and direct users to extend the image and install postgresql-18-jit for their use. But I am fine either way.

[reneleonhardt]

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

[reneleonhardt]

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) and 18-bookworm-jit.

[tianon]

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 extensions also 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.

[reneleonhardt]

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

[yosifkit]

Rebased to update template instead of build time detection

[tianon]

LGTM

I think we should probably wait to merge/publish this until we've got #1259 (or with it) so that we don't publish any versions of 18 that don't have that change. 👍

[Guiorgy]

For the JIT issue, would it be possible to have an environmental variable, something like INSTALL_JIT (probably set to true by default), and in the startup script you could check the flag and whether postgresql-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.

[reneleonhardt]

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.

[Guiorgy]

@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,