BUG #17943: Undefined symbol LLVMBuildGEP in llvmjit.so during pg_restore
The following bug has been logged on the website:
Bug reference: 17943
Logged by: Hans Buschmann
Email address: buschmann@nidsa.net
PostgreSQL version: 15.3
Operating system: Fedora 38 x86-64
Description:
I tried to restore our standard db from a recent dump on PostgreSQL 15.3
installed from PGDG repositories with dnf.
During pg_restore I got the following error message:
pg_restore: error: could not execute query: ERROR: could not load library
"/usr/pgsql-15/lib/llvmjit.so": /usr/pgsql-15/lib/llvmjit.so: undefined
symbol: LLVMBuildGEP
Command was: REFRESH MATERIALIZED VIEW archiv.mv_max_fac_order;
pg_restore: warning: errors ignored on restore: 1
For our system, jit isn't really important, but enabled in configuration.
So the error occurs only occasional here.
At the first attempt the following postgres / llvm packages where
installed:
postgresql15.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-contrib.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-devel.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-docs.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-libs.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-llvmjit.x86_64
15.3-1PGDG.f38 @pgdg15
postgresql15-server.x86_64
15.3-1PGDG.f38 @pgdg15
llvm.x86_64
16.0.3-1.fc38 @updates
llvm-devel.x86_64
16.0.3-1.fc38 @updates
llvm-libs.i686
16.0.3-1.fc38 @updates
llvm-libs.x86_64
16.0.3-1.fc38 @updates
llvm-static.x86_64
16.0.3-1.fc38 @updates
llvm-test.x86_64
16.0.3-1.fc38 @updates
llvm15-libs.x86_64
15.0.7-4.fc38 @fedora
Even after dnf remove llvm15-libs (leftover from a system upgrade from
Fedora 37) the same error persisted.
Any clues?
Hans Buschmann
On Thu, May 25, 2023 at 4:19 AM PG Bug reporting form
<noreply@postgresql.org> wrote:>
Any clues?
Is it possible that whoever packaged that compiled it against LLVM 15
but then put LLVM 16 into the package depencencies? I'm not a Fedora
user so that might be a silly question... but do you still have the
ability to install LLVM 15? Unfortunately PostgreSQL can't use LLVM16
yet, because we need to make some changes (hopefully in the next point
release):
/messages/by-id/CA+hUKGKNX_=f+1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw@mail.gmail.com
________________________________
Von: Wetmore, Matthew (CTR) <Matthew.Wetmore@express-scripts.com>
Gesendet: Mittwoch, 24. Mai 2023 19:27
An: Hans Buschmann
Betreff: BUG #17943: Undefined symbol LLVMBuildGEP in llvmjit.so during pg_restore
1. is the restore user the owner of the view (have to be owner to refresh) and do they have SELECT on the view's table(s)?
For clarification, this is a pg_restore of a full database dump as practiced for about 7 years now.
The test was under the builtin postgres role, so there seem no missing create role problems.
The sequence of commands is (abbreviated):
create database target_db;
(in another cmd window)
pg_restore -d target_db full_compressed_dump_from_pg15.dmp
From the same dumpfile a restore to an empty db in an instance without jit support has no problems.
2. REFRESH locks tables, are those tables built yet in the restore? Did you try CONCURRENTLY?
As this is a normal pg_restore I cannot influence order or locking.
I use pg_restore without CONCURRENTLY.
Hans Buschmann
Import Notes
Reply to msg id not found: 73e6193160a44474866472ceae1069ff@express-scripts.com
Hello Thomas,
Thank you for your information about LLVM16 support.
I noticed the discussion in hackers.
I wanted to point out that I used the standard repositories from PGDG15.
As to my knowledge they are packaged by Devrim, so this is the standard distribution for RedHat-style Linux on PGDG.
(This is shown by the dnf list lines in my OM)
I am not trying to use LLVM on my platform (tiny data, optimized SQL etc.) but I wanted to notice everybody that there are unreferenced symbols in llvmjit.so, something that should not happen.
I have no idea where this come from nor where it is used, but the unreferenced symbols should be at least masked with dummy rountines (or avoided) to prevent the error for other users where the problem matters much more!
Unfortunately this occurs on pg_restore, the ultimate backup/restore of a database, and data are not restored correctly and must be corrected manually afterwords.
Perhaps you could contact Devrim for clarification...
Hans Buschmann
________________________________
Hi,
On Thu, 2023-05-25 at 15:20 +1200, Thomas Munro wrote:
Is it possible that whoever packaged that compiled it against LLVM 15
but then put LLVM 16 into the package depencencies?
Me. The answer is yes.
I hit the same issue on my laptop a couple of days ago. Will rebuild
RPMs against LLVM15 (which is a separate package), and will release
until Monday.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR
On Thu, 2023-05-25 at 18:21 +0100, Devrim Gündüz wrote:
On Thu, 2023-05-25 at 15:20 +1200, Thomas Munro wrote:
Is it possible that whoever packaged that compiled it against LLVM 15
but then put LLVM 16 into the package depencencies?Me. The answer is yes.
I hit the same issue on my laptop a couple of days ago. Will rebuild
RPMs against LLVM15 (which is a separate package), and will release
until Monday.
I still see that error with the 16.0 packages on Fedora 38.
Yours,
Laurenz Albe
Hi Laurenz,
On Fri, 2023-09-15 at 09:06 +0200, Laurenz Albe wrote:
I still see that error with the 16.0 packages on Fedora 38.
Unfortunately Fedora 38 does not have clang15 package, so we'll need to
wait until PostgreSQL supports LLVM 16.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR
On Fri, 2023-09-15 at 12:28 +0100, Devrim Gündüz wrote:
On Fri, 2023-09-15 at 09:06 +0200, Laurenz Albe wrote:
I still see that error with the 16.0 packages on Fedora 38.
Unfortunately Fedora 38 does not have clang15 package, so we'll need to
wait until PostgreSQL supports LLVM 16.
I see.
Wouldn't it be better not to ship postgresql16-llvmjit, or at least to
ship PostgreSQL with "jit = off"?
Yours,
Laurenz Albe