Index: doc/src/sgml/client-auth.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v retrieving revision 1.83 diff -c -c -r1.83 client-auth.sgml *** doc/src/sgml/client-auth.sgml 14 Aug 2005 23:35:37 -0000 1.83 --- doc/src/sgml/client-auth.sgml 24 Oct 2005 15:30:13 -0000 *************** *** 337,342 **** --- 337,343 ---- authentication. Since the password is sent in clear text over the network, this should not be used on untrusted networks. + It also does not usually work with threaded client applications. See for details. Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.196 diff -c -c -r1.196 libpq.sgml *** doc/src/sgml/libpq.sgml 20 Oct 2005 23:57:51 -0000 1.196 --- doc/src/sgml/libpq.sgml 24 Oct 2005 15:30:15 -0000 *************** *** 4032,4037 **** --- 4032,4046 ---- fail if the server does not present a certificate; therefore, to use this feature the server must also have a root.crt file. + + + If you are using SSL inside your application (in addition to + inside libpq), you can use PQinitSSL(int) + to tell libpq that the SSL library + has already been initialized by your application. + + + *************** *** 4081,4092 **** ! libpq applications that use the ! crypt authentication method rely on the ! crypt() operating system function, which is often ! not thread-safe.cryptthread ! safety It is better to use the md5 method, ! which is thread-safe on all platforms. --- 4090,4101 ---- ! If you are using Kerberos inside your application (in addition to inside ! libpq), you will need to do locking around ! Kerberos calls because Kerberos functions are not thread-safe. See ! function PQregisterThreadLock in the ! libpq source code for a way to do cooperative ! locking between libpq and your application. Index: src/interfaces/libpq/fe-auth.c =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-auth.c,v retrieving revision 1.106 diff -c -c -r1.106 fe-auth.c *** src/interfaces/libpq/fe-auth.c 17 Oct 2005 16:24:20 -0000 1.106 --- src/interfaces/libpq/fe-auth.c 24 Oct 2005 15:30:16 -0000 *************** *** 500,505 **** --- 500,515 ---- struct passwd *pw = NULL; #endif + /* + * pglock_thread() really only needs to be called around + * pg_krb5_authname(), but some users are using configure + * --enable-thread-safety-force, so we might as well do + * the locking within our library to protect pqGetpwuid(). + * In fact, application developers can use getpwuid() + * in their application if they use the locking call we + * provide, or install their own locking function using + * PQregisterThreadLock(). + */ pglock_thread(); #ifdef KRB5 Index: src/interfaces/libpq/fe-secure.c =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v retrieving revision 1.72 diff -c -c -r1.72 fe-secure.c *** src/interfaces/libpq/fe-secure.c 15 Oct 2005 02:49:48 -0000 1.72 --- src/interfaces/libpq/fe-secure.c 24 Oct 2005 15:30:17 -0000 *************** *** 220,227 **** /* ! * Exported (but as yet undocumented) function to allow application to ! * tell us it's already initialized OpenSSL. */ void PQinitSSL(int do_init) --- 220,227 ---- /* ! * Exported function to allow application to tell us it's already ! * initialized OpenSSL. */ void PQinitSSL(int do_init)