Guys, just posted patches for libpq to address thread-safe issues. Now
uses strerror_r(), gethostbyname_r(), getpwuid_r() and crypt_r() where
available. Passes all tests on Linux and Solaris.
Any comments let me know - my first major(ish) outing in the
PostgreSQL source, in particular I'm not use in the configure stuff is
100% right...
Patches also at:
http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gzhttp://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz
Thanks, Lee.
Lee Kindness writes:> Tom Lane writes:> > Bruce Momjian <pgman@candle.pha.pa.us> writes:> > > We have definatly had
requestsfor 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
atleast we should.> > We do:> > http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html> >
ButLee's point about depending on possibly-unsafe libc routines is a> > good one. I don't think anyone's gone through
thecode with an eye to> > that.> > Right, so a reasonable angle for me to take is to go through the libpq> source
lookingfor 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-safeand cannot be made so> using standard library calls then it needs to be documented as such> both in the
sourceand the aforementioned documentation.> > This approach avoids any thread library dependencies and documents the>
currentstate 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>
areavailable to anyone who wants to play with ECPG and threads.> > Ta, Lee.