libpq thread safety

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: libpq thread safety
Date: 2003-11-17 21:55:48
Message-ID: 3FB943E4.90508@colorfullife.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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.
- pg_krb4_init(): Are the kerberos libraries thread safe? Additionally,
setting init_done is racy.
- 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.
- PQoidStatus: uses a static buffer.
- libpq_gettext: setting already_bound is racy.
- 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.

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.

--
Manfred

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniele Orlandi 2003-11-17 22:28:34 A big thanks to SuSE
Previous Message Erik Trulsson 2003-11-17 20:21:09 Re: 4 Clause license?

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-11-17 21:59:52 Re: initdb copyright notice
Previous Message Neil Conway 2003-11-17 21:15:25 Re: initdb copyright notice