Re: libpq thread safety

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