Re: libpq thread safety

Manfred Spraul wrote:
> Bruce Momjian wrote:
> 
> >How can we test if libpq needs to call that?  Seems that is an issue
> >whether we are threaded or not, no?
> >  
> >
> I think it's always an issue: in the non-threaded case, it's just not 
> fatal. At least some openssl init functions are protected with "if 
> (done) return; done = 1;", and it the worst case, it's a memory leak.
> With threaded apps,  it might corrupt a concurrent ssl transaction. 
> Perhaps PQenableSSLLocks could handle that case, too - a special flag 
> for skip SSL_library_init().

I see.

> >There is a new test program in src/tools/thread that needs to be run for
> >every platform for 7.5.  We can't use the 7.4.X tests because it didn't
> >report individual function tests, just one general value.  We need
> >individual test reports for 7.5.  Run the test program and post the
> >results and I will get it updated.  The test output on my bsd/os machine
> >is:
> >  
> >
> RedHat Fedora Core 1 and Debian 3.0 both report
> 
> <<
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
> 
> Add this to your template/$port file:
> 
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
> <<
> The uname's are
> Linux <snip> 2.4.25-1-686 #1 Tue Feb 24 10:55:59 EST 2004 i686 unknown 
> unknown GNU/Linux
> and
> Linux ab 2.4.22-1.2174.nptl #1 Wed Feb 18 16:38:32 EST 2004 i686 i686 
> i386 GNU/Linux
> 
> Both glibc 2.3.2, one with nptl, one with linuxthreads as the pthread 
> library.

template/linux updated.

--  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