Re: PATCH: Report libpq version and configuration

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: PATCH: Report libpq version and configuration
Дата
Msg-id CAGRY4ny3or8T9ny3EE85ZvuyxpwASa8af9SzODtgAbqQi4qTaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: Report libpq version and configuration  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Tue, Oct 27, 2020 at 12:41 AM Alvaro Herrera <alvherre@alvh.no-ip.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Add Information during standby recovery conflicts
Следующее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: Add important info about ANALYZE after create Functional Index