Thread: Re: System views for versions reporting
On 10/6/24 11:36, Dmitry Dolgov wrote: > Hi, > > Based on the feedback in [1], here is my attempt at implementing system > views for versions reporting. It adds pg_system_versions for showing > things like core version, compiler, LLVM, etc, and pg_system_libraries > for showing linked shared objects. I think everyone has ageed that the > first was a good idea, where the second was only suggested -- after some > thinking I find shared obects useful enough to include here as well. > > The main idea is to facilitate bug reporting. In particular, in many JIT > related bug reports one of the first questions is often "which LLVM > version is used?". Gathering such information is a manual process, > mistakes could be made when veryfing llvm-config output or anywhere > else. Having a system view for such purposes makes the process a bit > more robust. > > The first three patches are essential for this purpose, the fourth one > is somewhat independent and could be concidered in isolation. The output > looks like this : > > =# select * from pg_system_versions; > name | version | type > ----------+--------------+-------------- > Arch | x86_64-linux | Compile Time > ICU | 15.1 | Compile Time > Core | 18devel | Compile Time > Compiler | gcc-14.0.1 | Compile Time > LLVM | 18.1.6 | Run Time I'm not sure why ICU is "Compile Time" rather than "Run Time" when it is not statically linked. Also, if we are going to include ICU here, shouldn't we also include libc version? > =# select * from pg_system_libraries; > name > ----------------------------- > /lib64/libkrb5.so.3 > /lib64/libz.so.1 > linux-vdso.so.1 > /lib64/libxml2.so.2 > [...] > > Any feedback is appreciated. I think it would be nice to include a sha256 hash (or something similar) of the libraries as well, so that they can be checked against known good values. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Joe Conway <mail@joeconway.com> writes:
> I think it would be nice to include a sha256 hash (or something similar)
> of the libraries as well, so that they can be checked against known good
> values.
That seems well outside the charter of this patch. Also, how would
we even get that information? A typical application doesn't know
exactly what libraries it's linked with or where they came from on
the filesystem. Maybe one could find that out with sufficient
platform-specific hackery, but I don't believe we could do it
portably.
regards, tom lane
> On Sun, Oct 06, 2024 at 12:01:29PM GMT, Joe Conway wrote: > On 10/6/24 11:36, Dmitry Dolgov wrote: > > Hi, > > > > Based on the feedback in [1], here is my attempt at implementing system > > views for versions reporting. It adds pg_system_versions for showing > > things like core version, compiler, LLVM, etc, and pg_system_libraries > > for showing linked shared objects. I think everyone has ageed that the > > first was a good idea, where the second was only suggested -- after some > > thinking I find shared obects useful enough to include here as well. > > > > The main idea is to facilitate bug reporting. In particular, in many JIT > > related bug reports one of the first questions is often "which LLVM > > version is used?". Gathering such information is a manual process, > > mistakes could be made when veryfing llvm-config output or anywhere > > else. Having a system view for such purposes makes the process a bit > > more robust. > > > > The first three patches are essential for this purpose, the fourth one > > is somewhat independent and could be concidered in isolation. The output > > looks like this : > > > > =# select * from pg_system_versions; > > name | version | type > > ----------+--------------+-------------- > > Arch | x86_64-linux | Compile Time > > ICU | 15.1 | Compile Time > > Core | 18devel | Compile Time > > Compiler | gcc-14.0.1 | Compile Time > > LLVM | 18.1.6 | Run Time > > I'm not sure why ICU is "Compile Time" rather than "Run Time" when it is not > statically linked. It reports U_UNICODE_VERSION at compile time. It's not necessarily correct though, I can try to replace it with the runtime version. I think there was some ICU functionality (something like u_getUnicodeVersion), which is maybe a better fit. > Also, if we are going to include ICU here, shouldn't we > also include libc version? Yeah, why not. One of my goals here is to identify a balanced set of useful versions to report. > > =# select * from pg_system_libraries; > > name > > ----------------------------- > > /lib64/libkrb5.so.3 > > /lib64/libz.so.1 > > linux-vdso.so.1 > > /lib64/libxml2.so.2 > > [...] > > > > Any feedback is appreciated. > > I think it would be nice to include a sha256 hash (or something similar) of > the libraries as well, so that they can be checked against known good > values. I was thinking about getting more info to show in this view, but haven't found any reasonable way to achieve that. So I would agree with Tom on that.