-
Notifications
You must be signed in to change notification settings - Fork 470
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
Roadmap for bookworm migration #351
Comments
I've been considering this for a while, but it's not that simple. There are two expected issues with the new Debian version: b.) glibc + collation version mismatch Because of these issues, some people would prefer to stay with the bullseye version, but currently the postgis/docker-postgis repository only supports one Debian version. The ideal solution would be to support both Debian versions, for example:
But this would require significant restructuring, and I won't be able to start working on it in the next two weeks due to other commitments. |
@gbip : I wanted to let you know that I've started working on supporting multi-debian (bookworm, bullseye) and multi-alpine postgis images. I hope to provide a minimal Pull Request soon for testing. However, I cannot commit to a specific deadline yet. |
Will there be effort to support Postgis v12 using Bookworm? |
I'd definitely like to!
Development environment ( not stable ) - but you can check the plan : PR: #356 |
Hi, I am keen on this (I like the postgis docker image, and want to extend it with another extension that has pre-built binaries for bookworm) |
FYI - quick reminder that users can't safely switch from bullseye images to bookworm images without logical pg_dump-and-load or logical replication. Switching the container image from bullseye to bookworm and keeping the same storage (whether via PVCs or StatefulSets) can corrupt your database. Probably worth thinking about how this will work end-to-end. The cause is the stability issues with linguistic collation (especially in libc) and a number of database corruptions have happened in recent years related to this. Here's a talk from the postgres development conference earlier this year on the topic https://www.youtube.com/watch?v=KTA6oau7tl8 This is the same issue referenced by @ImreSamu above Supporting both bullseye and bookwork (similar to the base postgres image) should be fine |
While that's true, in most cases it's not real corruption, and you can fix it by refreshing the collation and/or rebuilding the affected indexes. More importantly, it applies just as well to a native (distro package) installation and to the base postgres image. Because of that, I don't think the postgis image should "gatekeep" bookworm. Bullseye is EOL, and this decision will only make it harder for users when trixie comes out. |
Hi,
Are there any plan to migrate from bullseye to bookworm ? How can we help ?
I am interested in using GEOS 3.11 features (for example ST_SimplifyPolygonHull), which is the version of GEOS available on debian bookworm.
Debian bullseye only has GEOS 3.9.0-1.
Best regards,
The text was updated successfully, but these errors were encountered: