Re: libpq thread safety

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.

--
Manfred