From: | Hans Buschmann <buschmann(at)nidsa(dot)net> |
---|---|
To: | "Wetmore, Matthew (CTR)" <Matthew(dot)Wetmore(at)express-scripts(dot)com>, PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | AW: BUG #17943: Undefined symbol LLVMBuildGEP in llvmjit.so during pg_restore |
Date: | 2023-05-25 07:12:40 |
Message-ID: | 33878dc6517d40ec90a29afd4fbde4b9@nidsa.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
________________________________
Von: Wetmore, Matthew (CTR) <Matthew(dot)Wetmore(at)express-scripts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hans Buschmann | 2023-05-25 07:30:58 | AW: BUG #17943: Undefined symbol LLVMBuildGEP in llvmjit.so during pg_restore |
Previous Message | Kyotaro Horiguchi | 2023-05-25 04:07:59 | Re: BUG #17942: vacuumdb doesn't populate extended statistics on partitioned tables |