Re: libpq thread safety

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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