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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073