Doc: Adjust libpq docs about thread safety.

Describe the situation now that --disable-thread-safety is gone.

Author: Heikki Linnakangas 
Discussion: https://postgr.es/m/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.gmail.com

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index b6f5aba1b1887d6208df63fdf9099a8c59ec43fd..a52baa27d563796e7676a6ce8a3a2dc7cf28cfc8 100644 (file)
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -9236,14 +9236,28 @@ void PQinitSSL(int do_ssl);
   
 
   
-   libpq is reentrant and thread-safe by default.
-   You might need to use special compiler command-line
-   options when you compile your application code.  Refer to your
-   system's documentation for information about how to build
-   thread-enabled applications, or look in
-   src/Makefile.global for PTHREAD_CFLAGS
-   and PTHREAD_LIBS.  This function allows the querying of
-   libpq's thread-safe status:
+   As of version 17, libpq is always reentrant and thread-safe.
+   However, one restriction is that no two threads attempt to manipulate
+   the same PGconn object at the same time. In particular,
+   you cannot issue concurrent commands from different threads through
+   the same connection object. (If you need to run concurrent commands,
+   use multiple connections.)
+  
+
+  
+   PGresult objects are normally read-only after creation,
+   and so can be passed around freely between threads.  However, if you use
+   any of the PGresult-modifying functions described in
+    or , it's up
+   to you to avoid concurrent operations on the same PGresult,
+   too.
+  
+
+  
+   In earlier versions, libpq could be compiled
+   with or without thread support, depending on compiler options. This
+   function allows the querying of libpq's
+   thread-safe status:
   
 
   
@@ -9261,29 +9275,12 @@ int PQisthreadsafe();
 
      
       Returns 1 if the libpq is thread-safe
-      and 0 if it is not.
+      and 0 if it is not. Always returns 1 on version 17 and above.
      
     
    
   
 
-  
-   One thread restriction is that no two threads attempt to manipulate
-   the same PGconn object at the same time. In particular,
-   you cannot issue concurrent commands from different threads through
-   the same connection object. (If you need to run concurrent commands,
-   use multiple connections.)
-  
-
-  
-   PGresult objects are normally read-only after creation,
-   and so can be passed around freely between threads.  However, if you use
-   any of the PGresult-modifying functions described in
-    or , it's up
-   to you to avoid concurrent operations on the same PGresult,
-   too.
-  
-
   
    The deprecated functions  and
     are not thread-safe and should not be