search

docker-library / postgres

Docker Official Image packaging for Postgres
http://www.postgresql.org
MIT License
2.16k stars 1.13k forks source link

In Postgres 12.15 Image, `LLVMBuildGEP` symbol not found. #1076

Closed StationSoen closed 1 year ago

StationSoen commented 1 year ago

Hello! I am using the Postgres 12 image and Django for my backend application.

However, after updating the Postgres 12 image to version 12.15, I encountered some failed operations due to the absence of LLVMBuildGEP.

The error message is as follows:

django.db.utils.OperationalError: could not load library "/usr/local/lib/postgresql/llvmjit.so": Error relocating /usr/local/lib/postgresql/llvmjit.so: LLVMBuildGEP: symbol not found.

Upon investigation, I discovered that the Alpine Linux version in the updated Postgres 12.15 image is now 3.18, and this version no longer includes LLVMBuildGEP because it was removed in LLVM 16. (LLVM 16 Release Notes)

I was able to resolve this issue by reverting my Postgres image version back to 12.14.

ImreSamu commented 1 year ago

I'm experiencing a similar issue with the https://github.com/postgis/docker-postgis - alpine3.18 test.

#7 157.9  ./core/regress_spgist_index_2d ..2023-05-12 05:05:53.730 UTC [11898] ERROR:  could not load library "/usr/local/lib/postgresql/llvmjit.so": Error relocating /usr/local/lib/postgresql/llvmjit.so: LLVMBuildGEP: symbol not found

(I'm just guessing) It might be necessary to build it with llvm15 until the upstream postgres resolves the compatibility with llvm16.

At least in Alpine3.18, postgresql12 built with llvm14.

EDIT:

basdebakker commented 1 year ago

We have the same issue with PostgreSQL 15. We are using the 15-alpine tag that was just updated to 15.3 and now run into this same error.

jonfinerty commented 1 year ago

This is also affecting the 13-alpine image, we've worked around in the meantime by pinning to the previous version, the 13.10-alpine tag.

thienandangthanh commented 1 year ago

I have the same issue with PostgreSQL 14. I are using the 14-alpine tag. I need to fallback to tag 14-alpine3.17 or 14.7-alpine with image id 9d94e6318ef2 to temporarily resolve the problem.

thienandangthanh commented 1 year ago

I understand that upgrading to alpine 3.18 or newer is vital. Because it mitigates the vulnerabilities. Sticking with a version is not a good idea.

@tianon, do you have any thought about this issue?

NorthBlue333 commented 1 year ago

I also have the same issue with Postgres 13-alpine3.18. :+1:

msand commented 1 year ago

I wonder, would it be enough to replace https://github.com/docker-library/postgres/blob/a23c0e97980edae5be2cd4eb68ff1f0762d031cd/Dockerfile-alpine.template#L49 With llvm15-dev clang15

yosifkit commented 1 year ago

I'm working on a PR for a fix and should have something up shortly. I'm also trying to work out a test so that we can verify the fix as well.

yosifkit commented 1 year ago

I have a simple test up in https://github.com/docker-library/official-images/pull/14646 that should help prevent this in the future. Once I can get that merged, I'll open the PR for my branch with the fix (https://github.com/infosiftr/postgres/commit/9768eb1d8521774600cbcdbdc02164ecb96abe42) so that the tests will run on the fix PR.

nekopsykose commented 1 year ago

We have the same issue with PostgreSQL 15. We are using the 15-alpine tag that was just updated to 15.3 and now run into this same error.

are you sure? postgres 15.3 supports llvm16 when built against and at runtime fine, since it was ported to LLVMBuildGEP2, afaik

(edit: disregard, i'm wrong)

kevinm416 commented 1 year ago

I also had this issue with postgresql:15-alpine. I pinned the version postgresql:15-alpine3.17 while this gets sorted out.

ImreSamu commented 1 year ago

@yosifkit :

I'll open the PR for my branch with the fix (https://github.com/infosiftr/postgres/commit/9768eb1d8521774600cbcdbdc02164ecb96abe42) so that the tests will run on the fix PR.

Thank you!

comment:

As I understand that for the downstream ( ~ Postgis ) build script ( https://github.com/postgis/docker-postgis/blob/b50183f2244f42904d95d2bac3a12d1f16b4e59a/Dockerfile.alpine.template#L85 ) , it's necessary to install the exact same LLVM version. and currently, identifying the linked LLVM version via the command line can be a bit challenging.

I don't know what the recommended method for determining the linked LLVM version is, but if there is a recommendation, it would be advisable to include it in the documentation.

yosifkit commented 1 year ago

or could we consider creating an environment variable for the LLVM version? (e.g., ENV PG_LLVM 15 )

I hadn't considered that postgis and other extensions would need to install the same llvm-dev/clang versions. 🤔 I think an ENV could make sense. Do they need other values like LLVM_CONFIG and CLANG too?

yosifkit commented 1 year ago

Would a package list in the env var work to lower duplication that extensions would have to do? Like we have for php: https://github.com/docker-library/php/blob/0a68eaa2d3a269079c687e55abc960c77d3a134e/8.2/alpine3.18/cli/Dockerfile#L11-L20.