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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
