Re: PATCH: Report libpq version and configuration - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: PATCH: Report libpq version and configuration
Date
Msg-id CAGRY4nwTP46nEruTeKbc=WSf=-TGeCK_Q6vq46QZM1SKbVVWWQ@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Report libpq version and configuration  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PATCH: Report libpq version and configuration  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
On Tue, Nov 10, 2020 at 12:33 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Well, if we can make it run in more systems than just Linux, then it
> seems worth having.  The submitted patch seems a little bit on the
> naughty side.

I agree that the facility seems possibly useful, as long as we can
minimize its platform dependency.  Just embedding some strings, as
I suggested upthread, seems like it'd go far in that direction.
Yeah, you could spend a lot of effort to make it a bit more user
friendly, but is the effort really going to be repaid?  The use
case for this isn't that large, I don't think.

The reason I want to expose symbols is mainly for tracing tooling - perf, systemtap, etc.

I thought it'd make sense to also provide another way to identify the libpq binary.

My other hesitation about using a "strings libpq.so" approach is that it's not something I'd be super happy about automating and relying on in scripts etc. It could break depending on how the compiler decides to arrange things or due to unrelated changes in libpq that create similar-looking strings later. I'd prefer to do it deterministically. You can already use "strings" to identify an unstripped binary built with -ggdb3 (macros in DWARF debuginfo), but we don't compile the PG_VERSION into the binary, so you can't even get the basic version string like "postgres (PostgreSQL) 11.9" from 'strings'.

The whole PQlibInfo() thing came about because I thought it'd be potentially useful. I've had issues before with applications being built against a newer version of libpq than what they're linked against, and it's been rather frustrating to make the app tolerant of that. But it can be solved (clumsily) using various existing workarounds.

The main things I'd really like to get in place are a way to get the version as an ELF data symbol, and a simple way to ID the binary.

So the minimal change would be to declare:

const char LIBPQ_VERSION_STR[] = PG_VERSION_STR;
const int LIBPQ_VERSION_NUM = PG_VERSION_NUM;

then change PQgetVersion() to return LIBPQ_VERSION_NUM and add a PQgetVersionStr() that returns LIBPQ_VERSION_STR.

That OK with you?


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: MultiXact\SLRU buffers configuration
Next
From: Michael Paquier
Date:
Subject: Re: abstract Unix-domain sockets