| From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add llvm version into the version string |
| Date: | 2024-09-22 11:15:54 |
| Message-ID: | u74dgzwrfbnqyi6qvgvt5rv4znt54ecelcvm6ibdkwznggtkhg@rkcwncucff7v |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Sat, Sep 21, 2024 at 05:25:30PM GMT, Tom Lane wrote:
>
> Is there a way to get the llvm library's version at run time? If so
> we could consider building a new function to return that.
Yes, there is a C api LLVMGetVersion to get the major, minor and patch
numbers. The jit provider could be extended to return this information.
About a new function, I think that the llvm runtime version has to be
shown in some form by pgsql_version. The idea is to skip an emails
exchange like "here is the bug report" -> "can you attach the llvm
version?". If it's going to be a new separate function, I guess it won't
make much difference to ask either to call the new function or the
llvm-config, right?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2024-09-22 11:44:31 | Re: Inconsistency in reporting checkpointer stats |
| Previous Message | Tatsuo Ishii | 2024-09-22 08:59:34 | Re: pgbench: Improve result outputs related to failed transactinos |