Thread: Re: Add llvm version into the version string

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> In many jit related bug reports, one of the first questions is often
> "which llvm version is used". How about adding it into the
> PG_VERSION_STR, similar to the gcc version?

I'm pretty down on this idea as presented, first because our version
strings are quite long already, and second because llvm is an external
library.  So I don't have any faith that what llvm-config said at
configure time is necessarily the exact version we're using at run
time.  (Probably, the major version must be the same, but that doesn't
prove anything about minor versions.)

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.

            regards, tom lane

> 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?

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> On Sun, Sep 22, 2024 at 01:15:54PM GMT, Dmitry Dolgov wrote:
>> 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?".

I'm not in favor of that, for a couple of reasons:

* People already have expectations about what version() returns.
Some distro and forks even modify it (see eg --extra-version).
I think we risk breaking obscure use-cases if we add stuff onto that.
Having version() return something different from the PG_VERSION_STR
constant could cause other problems too, perhaps.

* Believing that it'll save us questioning a bug submitter seems
fairly naive to me.  Nobody includes the result of version() unless
specifically asked for it.

* I'm not in favor of overloading version() with subsystem-related
version numbers, because it doesn't scale.  Who's to say we're not
going to need the version of ICU, or libxml2, to take a couple of
obvious examples?  When you take that larger view, multiple
subsystem-specific version functions seem to me to make more sense.

Maybe another idea could be a new system view?

=> select * from pg_system_version;
     property     |     value
----------------------------------------
 core version     | 18.1
 architecture     | x86_64-pc-linux-gnu
 word size        | 64 bit
 compiler         | gcc (GCC) 12.5.0
 ICU version      | 60.3
 LLVM version     | 18.1.0
 ...

Adding rows to a view over time seems way less likely to cause
problems than messing with a string people probably have crufty
parsing code for.

>> 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?

I do think that if we can get a version number out of the loaded
library, that is worth doing.  I don't trust the llvm-config that
happens to be in somebody's PATH to be the same version that their
PG is actually built with.

            regards, tom lane

> On Mon, Sep 23, 2024 at 02:45:18PM GMT, Tom Lane wrote:
> Maybe another idea could be a new system view?
>
> => select * from pg_system_version;
>      property     |     value
> ----------------------------------------
>  core version     | 18.1
>  architecture     | x86_64-pc-linux-gnu
>  word size        | 64 bit
>  compiler         | gcc (GCC) 12.5.0
>  ICU version      | 60.3
>  LLVM version     | 18.1.0
>  ...
>
> Adding rows to a view over time seems way less likely to cause
> problems than messing with a string people probably have crufty
> parsing code for.

Agree, the idea with a new system view sounds interesting. I'll try to
experiment in this direction, thanks.

Hi,

On 2024-09-24 13:53:49 +0100, Alastair Turner wrote:
> Since the build and runtime versions may differ for some things like llvm,
> libxml2 and the interpreters behind some of the PLs, it may be valuable to
> expand the view and show two values - a build time (or configure time)
> value and a runtime value for these.

+1

Somewhat orthogonal: I've wondered before whether it'd be useful to have a
view showing the file path and perhaps the soversion of libraries dynamically
loaded into postgres. That's currently hard to figure out over a connection
(which is all a lot of our users have access to).

Greetings,

Andres Freund

On 9/24/24 09:52, Andres Freund wrote:
> Hi,
> 
> On 2024-09-24 13:53:49 +0100, Alastair Turner wrote:
>> Since the build and runtime versions may differ for some things like llvm,
>> libxml2 and the interpreters behind some of the PLs, it may be valuable to
>> expand the view and show two values - a build time (or configure time)
>> value and a runtime value for these.
> 
> +1
> 
> Somewhat orthogonal: I've wondered before whether it'd be useful to have a
> view showing the file path and perhaps the soversion of libraries dynamically
> loaded into postgres. That's currently hard to figure out over a connection
> (which is all a lot of our users have access to).

+1

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com