Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >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.
> >
> A callback based implementation can handle that: libpq has a default
> implementation for apps that do not use openssl or kerberos themself. If
> the app wants to use the libraries, too, then it must replace the hooks
> with their own locks.
>
> I've attached a simple proposal, just for kerberos 4. If you agree on
> the general approach, I'll add it to all functions that are not thread safe.
>
> > 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.
> >
> >
> It means that multithreading is not usable: As Tom explained, the
> connect string is often set directly by the end user. Setting "sslmode"
> would result is races - impossible to support. In the very least,
> sslmode and Kerberos would have to fail if the app is multithreaded.
>
I think it is even worse than you state. SSL and Kerberos is mostly
controlled by pg_hba.conf, not the client connection string.
Also, while we create a thread-aware libpq, we don't actually have any
way to test if threads are being used by the application.
Let's go in this direction for Kerberos and SSL, and I can modify the
libpq docs on threading.
-- 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