From: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: Report libpq version and configuration |
Date: | 2020-10-27 00:51:47 |
Message-ID: | CAGRY4ny3or8T9ny3EE85ZvuyxpwASa8af9SzODtgAbqQi4qTaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 27, 2020 at 12:41 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
> On 2020-Oct-26, Craig Ringer wrote:
>
> > Patch 0001 adds PQlibInfo(), which returns an array of key/value
> > description items reporting on configuration like the full version
> string,
> > SSL support, gssapi support, thread safety, default port and default unix
> > socket path. This is for application use and application diagnostics. It
> > also adds PQlibInfoPrint() which dumps PQlibInfo() keys/values to stdout.
> > See the commit message in patch 0001 for details.
>
> Sounds useful. I'd have PQlibInfoPrint(FILE *) instead, so you can pass
> stdout or whichever fd you want.
>
The decision not to do so was deliberate. On any platform where a shared
library could be linked to a different C runtime library than the main
executable or other libraries it is not safe to pass a FILE*. This is most
common on Windows.
I figured it's just a trivial wrapper anyway, so people can just write or
copy it if they really care.
> Patch 0002 exposes LIBPQ_VERSION_STR, LIBPQ_VERSION_NUM and
> > LIBPQ_CONFIGURE_ARGS symbols in the dynamic symbol table. These can be
> > accessed by a debugger even when the library cannot be loaded or
> executed,
> > and unlike macros are available even in a stripped executable. So they
> can
> > be used to identify a libpq binary found in the wild. Their storage is
> > shared with PQlibInfo()'s static data, so they only cost three symbol
> table
> > entries.
>
> Interesting. Is this real-world useful? I'm thinking most of the time
> I'd just run the library, but maybe you know of cases where that doesn't
> work?
>
It was prompted by a support conversation about how to identify a libpq.
So I'd say yes.
In that case the eventual approach used was to use Python's ctypes to
dynamically load libpq then call PQlibVersion().
> Patch 0003 allows libpq.so to be executed directly from the command line
> to
> > print its version, configure arguments etc exactly as PQlibInfoPrint()
> > would output them. This is only enabled on x64 linux for now but can be
> > extended to other targets quite simply.
>
> +1 --- to me this is the bit that would be most useful, I expect.
>
It's also kinda cool.
But it's using a bit of a platform quirk that's not supported by the
toolchain as well as I'd really like - annoyingly, when you pass a
--entrypoint to GNU ld or to LLVM's ld.lld, it should really emit the
default .interp section to point to /bin/ld.so.2 or
/lib64/ld-linux-x86-64.so.2 as appropriate. But when building -shared they
don't seem to want to, nor do they expose a sensible macro that lets you
get the default string yourself.
So I thought there was a moderate to high chance that this patch would trip
someone's "yuck" meter.
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolay Samokhvalov | 2020-10-27 01:29:07 | Re: Add important info about ANALYZE after create Functional Index |
Previous Message | Masahiko Sawada | 2020-10-27 00:41:14 | Re: Add Information during standby recovery conflicts |