Re: PostgreSQL libraries - PThread Support, but not use... - Mailing list pgsql-hackers

We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help.  We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.  We have been making
marginal thread-safe improvements over the years.

---------------------------------------------------------------------------

Lee Kindness wrote:
> Tom Lane writes:
>  > Lee Kindness <lkindness@csl.co.uk> writes:
>  > > On a slightly related note to the other threads thread [sic] going
>  > > on... Over the Christmas/New Year break i've been looking into making
>  > > the PostgreSQL client libraries (in particular libpq and ecpg)
>  > > thread-safe - that is they can safely be used by a program which
>  > > itself is using mutliple threads. I'm largely there with ecpg (globals
>  > > are protected, a sqlca for each thread), but of course it relies on
>  > > libpq which needs work to share a connection between thrreads.
>  > 
>  > AFAIK, libpq is thread-safe already, it's just not thread-aware.
>  > What you'd presumably want is a wrapper layer that adds a mutex to
>  > prevent multiple threads from manipulating a PGconn at the same time.
>  > Couldn't this be done without touching libpq at all?
> 
> Certainly, it could. I've not fully investigated the current failings
> of libpq WRT to threading yet. But it's certainly a bit more than I
> stated above. I don't know where the statement that libpq is thread
> safe originated from (I see it's on the website). but at a quick
> glance I believe that krb4, krb5, PQoidStatus(),
> PQsetClientEncoding(), winsock_strerror() need more though
> investigation and non-thread-safe fuctions are also being used (at a
> glance gethostbyname() and strtok()).
> 
>  > > 1. It's looking likely that the libraries will need to link to
>  > > libpthread, and as a result anything linking to the libraries will
>  > > need to link to libpthread too. Will this be accepted in a patch?
>  > If the patch requires pthread and not any other form of thread support,
>  > probably not.  See nearby threading thread ;-)
>  > In general I'd be unhappy with doing anything to libpq that forces
>  > non-threaded clients to start depending on libpthread (or other thread
>  > libraries).  Thus the idea of a wrapper seems more appealing to me.
> 
> Okay, but what about ecpg? Thread-local sqlca instances would be a
> real benefit, guess Michael and Christof are the guys to talk to?
> 
> I suppose the real problem is the needed baggage with this - the
> autoconf macros will be a nightmare!
> 
> Thanks, Lee.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073