database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-25 21:42:33 +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>
<para>
<application>libpq</application> 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
<filename>src/Makefile.global</filename> for <literal>PTHREAD_CFLAGS</literal>
and <literal>PTHREAD_LIBS</literal>. This function allows the querying of
<application>libpq</application>'s thread-safe status:
As of version 17, <application>libpq</application> is always reentrant and thread-safe.
However, one 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>
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>
<variablelist>
@ -9261,29 +9275,12 @@ int PQisthreadsafe();
<para>
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>
</listitem>
</varlistentry>
</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>
The deprecated functions <xref linkend="libpq-PQrequestCancel"/> and
<xref linkend="libpq-PQoidStatus"/> are not thread-safe and should not be