How can we test if libpq needs to call that? Seems that is an issueI 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.
whether we are threaded or not, no?
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().
There is a new test program in src/tools/thread that needs to be run forRedHat Fedora Core 1 and Debian 3.0 both report
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:
<< 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.
-- Manfred
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
