Manfred Spraul wrote: > Hi, > > I've searched through libpq and looked for global or static variables as > indicators of non-threadsafe code. I found: > - Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it > seems to be a dummy variable that is always discarded.
Right, and it is moving into a compatibility function in 7.5 where it will be a local function variable. > - pg_krb4_init(): Are the kerberos libraries thread safe? Additionally, > setting init_done is racy. No idea. > - pg_krb4_authname(): uses a static buffer. > - kerberos 5: Is the library thread safe? the initialization could run > twice, I'm not sure if that's intentional. > - pg_krb4_authname(): relies on the global variable pg_krb5_name. Seems kerberos isn't. > - PQoidStatus: uses a static buffer. Yes, known documented problem. > - libpq_gettext: setting already_bound is racy. Does that happen in different threads? > - openssl: According to > http://www.openssl.org/docs/crypto/threads.html > libpq must register locking callbacks within openssl, otherwise there > will be random corruptions. Additionally the SSL_context initialization > is not properly synchronized, and SSLerrmessage relies on a static buffer. Oh. > PQoidStatus is already documented as not thread safe, but what about > OpenSSL and kerberos? It seems openssl needs support with callbacks, and > according to google searches MIT kerberos 5 is not thread safe, and > libpq must use mutexes to prevent concurrent calls into the kerberos > library. Oh, seems like a TODO here. We already know how to do thread locking in port/thread.c so maybe we just need to add some locks in there. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match