Thread: Re: [GENERAL] Querying libpq compile time options

Re: [GENERAL] Querying libpq compile time options

From
Bruce Momjian
Date:
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. +


Re: [GENERAL] Querying libpq compile time options

From
Date:
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

Re: [GENERAL] Querying libpq compile time options

From
Martijn van Oosterhout
Date:
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.

Re: [GENERAL] Querying libpq compile time options

From
Bruce Momjian
Date:
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;
    }
}

Re: [GENERAL] Querying libpq compile time options

From
Tom Lane
Date:
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