database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-20 00:42:27 +03:00
Code

Doc: Adjust libpq docs about thread safety.

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

Author: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.gmail.com
This commit is contained in:
Thomas Munro 2023-07-12 08:57:55 +12:00
parent 68a4b58eca
commit ce0b0fa3e7
1 changed files with 23 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/src/sgml/libpq.sgml
View File

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