On 03/07/2023 10:29, Peter Eisentraut wrote:
On 10.06.23 07:26, Andres Freund wrote:
-###############################################################
-# Threading
-###############################################################
-
-# XXX: About to rely on thread safety in the autoconf build, so not worth
-# implementing a fallback.
-cdata.set('ENABLE_THREAD_SAFETY', 1)
I wonder if we should just unconditionally set that in c.h or such? It'd not
be crazy for external projects to rely on that being set.
We definitely should keep the mention in ecpg_config.h.in, since that is
explicitly put there for client code to use. We keep HAVE_LONG_LONG_INT
etc. there for similar reasons.
+1. Patches 1-3 look good to me, with the things Andres & Peter already
pointed out.
The docs at https://www.postgresql.org/docs/current/libpq-threading.html
needs updating. It's technically still accurate, but it ought to at
least mention that libpq on v17 and above is always thread-safe. I
propose the attached. It moves the note on "you can only use one PGConn
from one thread at a time" to the top, before the description of the
PQisthreadsafe() function.
On 10/06/2023 05:23, Thomas Munro wrote:
2. I don't like the way we have to deal with POSIX vs Windows at
every site where we use threads, and each place has a different style
of wrappers. I considered a few different approaches to cleaning this
up:
* provide centralised and thorough pthread emulation for Windows; I
don't like this, I don't even like all of pthreads and there are many
details to get lost in
* adopt C11 <threads.h>; unfortunately it is too early, so you'd need
to write/borrow replacements for at least 3 of our 11 target systems
* invent our own mini-abstraction for a carefully controlled subset of stuff
Google search on "c11 threads on Windows" found some emulation wrappers:
https://github.com/jtsiomb/c11threads and
https://github.com/tinycthread/tinycthread, for example. Would either of
those work for us?
Even if we use an existing emulation wrapper, I wouldn't mind having our
own pg_* abstration on top of it, to document which subset of the POSIX
or C11 functions we actually use.
--
Heikki Linnakangas
Neon (https://neon.tech)
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 2225e4e0ef..bef03cfa16 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -9129,14 +9129,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>
@@ -9154,29 +9168,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
