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.
hi. https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318 shows lots of failures, but it doesn't seem to tell you about doc build failure. + <sect1 id="view-pg-system-versions"> + <title><structname>pg_system_versions</structname></title> + + <indexterm zone="view-pg-system-version"> + <primary>pg_system_versions</primary> + </indexterm> + <indexterm zone="view-pg-system-version"> should change to + <indexterm zone="view-pg-system-versions"> otherwise cannot build doc. + <table> + <title><structname>pg_system_versions</structname> Columns</title> + <tgroup cols="1"> ... column "type" of view pg_system_versions is missing in the doc entry ? + if (found) + ereport(ERROR, + (errcode(ERRCODE_DUPLICATE_OBJECT), + errmsg("duplicated system version"))); this is unlikely to happen (not user visible error), normally we should just use elog(ERROR...) ? +typedef enum VersionType +{ + CompileTime, + RunTime, +} VersionType; + +typedef struct SystemVersion +{ + char name[NAMEDATALEN]; /* Unique component name, used as a key + * for versions HTAB */ + VersionType type; + SystemVersionCB callback; /* Callback to fetch the version string */ +} SystemVersion; these two structs also need to be added into src/tools/pgindent/typedefs.list? --- a/src/include/utils/system_version.h +++ b/src/include/utils/system_version.h @@ -11,6 +11,7 @@ #ifndef SYSTEM_VERSION_H #define SYSTEM_VERSION_H +#include <gnu/libc-version.h> #include <link.h> "gnu/libc-version.h" does not exist in the clang compiler? will "link.h" everywhere? Currently, only a few rows are displayed for pg_system_versions. If I have linked a dependency, I should be able to retrieve its version—for example, I should be able to determine the version of zstd (i have linked the zstd dependency).
On 2025-01-02 10:36:48 +0800, jian he wrote: > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318 > shows lots of failures, but it doesn't seem to tell you about doc build > failure. It does: https://cirrus-ci.com/task/6472750665039872?logs=docs_build#L0 [15:26:26.443] time make -s -j${BUILD_JOBS} -C doc [15:26:28.759] postgres.sgml:5082: element indexterm: validity error : IDREFS attribute zone references an unknown ID "view-pg-system-version"