Document the SSL and Kerberos are not thread-safe.

bmomjian · bmomjian · commit 0f8c4bc4a291 · 2004-03-11T02:39:10.000Z
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.146 2004/01/26 22:13:21 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.147 2004/03/11 02:39:10 momjian Exp $
 -->
 
  <chapter id="libpq">
@@ -3630,7 +3630,8 @@ call <function>fe_setauthsvc</function> at all.
 <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.
+which is thread-safe on all platforms.  <application>SSL</> connections
+and <application>kerberos</> authentication are also not thread-safe.
 </para>
 
 <para>
@@ -3645,7 +3646,7 @@ completion. When <literal>--enable-thread-safety</> is used,
 before the first database connection if no custom <literal>SIGPIPE</>
 handler has been installed previously. This handler uses thread-local
 storage to determine if a <literal>SIGPIPE</> signal has been generated
-by an internal <function>send()</>. If an application wants to install
+by a libpq <function>send()</>. If an application wants to install
 its own <literal>SIGPIPE</> signal handler, it should call
 <function>PQinSend()</> to determine if it should ignore the
 <literal>SIGPIPE</> signal. This function is available in both
