Thread: Re: [GENERAL] Querying libpq compile time options
spaminos-sql@yahoo.com wrote: > Hi all > > I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic library being usedhas been compiled with the right option. > How do I do this? > > Is there a call such as "bool PQisThreadSafe()" that I can call? [ Email moved to hackers list.] Good question. This has come up a few times. You can check if the installation has threading with "pg_config --configure", and I though there was a way to test at runtime, but looking I don't see anything. Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do we need to add a libpq function to return true/false for threading? Slony requires a threaded libpq, so it could do the test to prevent wrong configurations. It would be nice to enabled threading by default, but it is like SSL in that not all operating systems support it. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
From: Bruce Momjian <pgman@candle.pha.pa.us>
> spaminos-sql@yahoo.com wrote:
> > Hi all
> >
> > I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic
> > library being used has been compiled with the right option.
> > How do I do this?
> >
> > Is there a call such as "bool PQisThreadSafe()" that I can call?
> Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
> we need to add a libpq function to return true/false for threading?
> Slony requires a threaded libpq, so it could do the test to prevent
> wrong configurations. It would be nice to enabled threading by default,
> but it is like SSL in that not all operating systems support it.
Yes, this is exactly the issue I have: I want to enforce at runtime that the library being
used is correct.
btw, I noticed that for some reason the prebuild linux rpms for Fedora Core 3 are compiled
without pthread support (and that's how I found out that I had to check the library on startup as I was getting strange lockups).
I think the simplest is to add a new call just like the one you described for testing for ssl and tell people
to call this function if they need the library to be thread safe.
Nicolas
> > Hi all
> >
> > I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic
> > library being used has been compiled with the right option.
> > How do I do this?
> >
> > Is there a call such as "bool PQisThreadSafe()" that I can call?
> Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
> we need to add a libpq function to return true/false for threading?
> Slony requires a threaded libpq, so it could do the test to prevent
> wrong configurations. It would be nice to enabled threading by default,
> but it is like SSL in that not all operating systems support it.
Yes, this is exactly the issue I have: I want to enforce at runtime that the library being
used is correct.
btw, I noticed that for some reason the prebuild linux rpms for Fedora Core 3 are compiled
without pthread support (and that's how I found out that I had to check the library on startup as I was getting strange lockups).
I think the simplest is to add a new call just like the one you described for testing for ssl and tell people
to call this function if they need the library to be thread safe.
Nicolas
On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote: > Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do > we need to add a libpq function to return true/false for threading? > Slony requires a threaded libpq, so it could do the test to prevent > wrong configurations. It would be nice to enabled threading by default, > but it is like SSL in that not all operating systems support it. PQgetssl() doesn't tell you if SSL is supported, it tells you if the *current connection* is using OpenSSL, which is similar but not the same. There is AFAIK no way to tell if SSL support is compiled in. Part of the patch I posted for GnuTLS support answered this question also (PQgettlsinfo()). Have a ncie day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote: > > Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do > > we need to add a libpq function to return true/false for threading? > > Slony requires a threaded libpq, so it could do the test to prevent > > wrong configurations. It would be nice to enabled threading by default, > > but it is like SSL in that not all operating systems support it. > > PQgetssl() doesn't tell you if SSL is supported, it tells you if the > *current connection* is using OpenSSL, which is similar but not the > same. > > There is AFAIK no way to tell if SSL support is compiled in. Part of > the patch I posted for GnuTLS support answered this question also > (PQgettlsinfo()). I thought about this. Attached is a patch you can use to popen("pg_config") and then look for the thread flag to configure. One idea would be to add this sample to our libpq documentation. The problem with the example is popen() overhead, pg_config not in $PATH, or pg_config's version not matching libpq's version. A more comprehensive idea would be to embed the configure string in libpq, like we do for pg_config, and allow that to be returned to the caller so they can do a strstr() to see if a certain flag was used. Having per-configure flag functions, like for threading, seems like it could be a mess because there is a lot more application programmers might care about in addition to threading, like SSL, multi-byte, etc. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + /* * This function queries pg_config to check for specific * configure flags used to build PostgreSQL. It can be * easily modified to return true/false to the caller. * This example tests thread safety. */ #include <stdio.h> #include <string.h> #define PG_CONFIG_CMD "pg_config --configure" /* * pg_config's output should fit in one string because we don't want * the search string to split across reads. */ #define POPEN_READ 8192 int main(int argc, char *argv[]) { FILE *p; char str[POPEN_READ]; if ((p = popen(PG_CONFIG_CMD, "r")) == NULL || fgets(str, POPEN_READ, p) == NULL) { fprintf(stderr, "Cannot run \"%s\", perhaps incorrect $PATH", PG_CONFIG_CMD); if (p) pclose(p); exit(2); } pclose(p); if (strstr(str, "--enable-thread-safety") != NULL) { puts("threading enabled"); return 0; } else { puts("threading not enabled"); return 1; } }
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I thought about this. Attached is a patch you can use to > popen("pg_config") and then look for the thread flag to configure. One > idea would be to add this sample to our libpq documentation. The > problem with the example is popen() overhead, pg_config not in $PATH, or > pg_config's version not matching libpq's version. Yeah, the last point seems like a killer objection :-(. It'd be better to add some sort of libpq function to handle the issue. regards, tom lane