From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Manfred Spraul <manfred(at)colorfullife(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq thread safety |
Date: | 2004-03-11 02:38:52 |
Message-ID: | 200403110238.i2B2cqi14318@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian wrote:
> 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.
Done.
>
> > - 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.
What killed the idea of doing ssl or kerberos locking inside libpq was
that there was no way to be sure that outside code didn't also access
those routines. I have documented that SSL and Kerberos are not
thread-safe in the libpq docs. Let's wait and see If we need additional
work in this area.
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | zhuangjifeng | 2004-03-11 03:55:09 | why not ADTs? |
Previous Message | Andrew Dunstan | 2004-03-11 02:28:31 | Re: selective statement logging |
From | Date | Subject | |
---|---|---|---|
Next Message | Shachar Shemesh | 2004-03-11 05:05:30 | Re: Defining a "tinyint" data type - one byte unsigned |
Previous Message | Bruce Momjian | 2004-03-11 02:23:31 | Re: change output of \dp |