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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
