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 <xref linkend="auth-password"> for details.
</para>
</listitem>
fail if the server does not present a certificate; therefore, to
use this feature the server must also have a <filename>root.crt</> file.
</para>
+
+ <para>
+ If you are using <acronym>SSL</> inside your application (in addition to
+ inside <application>libpq</application>), you can use <function>PQinitSSL(int)</>
+ to tell <application>libpq</application> that the <acronym>SSL</> library
+ has already been initialized by your application.
+ </para>
+
+
</sect1>
</para>
<para>
-<application>libpq</application> applications that use the
-<literal>crypt</literal> authentication method rely on the
-<literal>crypt()</literal> operating system function, which is often
-not thread-safe.<indexterm><primary>crypt</><secondary>thread
-safety</></> It is better to use the <literal>md5</literal> method,
-which is thread-safe on all platforms.
+If you are using Kerberos inside your application (in addition to inside
+<application>libpq</application>), you will need to do locking around
+Kerberos calls because Kerberos functions are not thread-safe. See
+function <function>PQregisterThreadLock</> in the
+<application>libpq</application> source code for a way to do cooperative
+locking between <application>libpq</application> and your application.
</para>
<para>
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