Skip to content

chore: add postgres 18 beta1 #1344

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

reneleonhardt
Copy link
Contributor

@reneleonhardt reneleonhardt commented May 31, 2025

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
Copy link
Member

tianon commented Jun 2, 2025

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

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
Copy link
Contributor Author

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
Copy link
Member

tianon commented Jun 2, 2025

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
Copy link
Contributor Author

I removed s390x.

@yosifkit
Copy link
Member

yosifkit commented Jun 2, 2025

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

tianon commented Jun 3, 2025

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 reneleonhardt force-pushed the chore/add-postgres-18 branch from 56b355c to 84c8a38 Compare June 3, 2025 18:45
@reneleonhardt
Copy link
Contributor Author

reneleonhardt commented Jun 3, 2025

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 yosifkit force-pushed the chore/add-postgres-18 branch from 84c8a38 to 08ab1eb Compare June 4, 2025 21:11
@yosifkit
Copy link
Member

yosifkit commented Jun 4, 2025

Rebased to update template instead of build time detection

@yosifkit yosifkit force-pushed the chore/add-postgres-18 branch from 08ab1eb to d1e97f2 Compare June 4, 2025 22:38
Copy link
Member

@tianon tianon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

Guiorgy commented Jun 6, 2025

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
Copy link
Contributor Author

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
Copy link

Guiorgy commented Jun 6, 2025

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

@yosifkit yosifkit merged commit c257dcc into docker-library:master Jun 6, 2025
38 checks passed
docker-library-bot added a commit to docker-library-bot/official-images that referenced this pull request Jun 6, 2025
Changes:

- docker-library/postgres@6ec0e42: Merge pull request docker-library/postgres#1259 from infosiftr/pgdata-cluster
- docker-library/postgres@2c6fe8d: Add logic to error out on detection of "old databases"
- docker-library/postgres@b9a533c: Change `PGDATA` in 18+ to `/var/lib/postgresql/MAJOR/docker`
- docker-library/postgres@c257dcc: Merge pull request docker-library/postgres#1344 from reneleonhardt/chore/add-postgres-18
- docker-library/postgres@d1e97f2: add postgres 18 beta1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants