Tom Lane writes:> Bruce Momjian <pgman@candle.pha.pa.us> writes:> > We have definatly had requests for improved
thread-safenessfor 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
do:>http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html> But Lee's point about depending
onpossibly-unsafe libc routines is a> good one. I don't think anyone's gone through the code with an eye to> that.
Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.
If any function is found to be not thread-safe and cannot be made so
using standard library calls then it needs to be documented as such
both in the source and the aforementioned documentation.
This approach avoids any thread library dependencies and documents the
current state of play WRT thread safety (i.e it's a good, and needed,
basis for any later work).
ECPG is a separate issue, and best handled as such (it will need
thread calls). I'll post a patch for it at a later date so the changes
are available to anyone who wants to play with ECPG and threads.
Ta, Lee.
