</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>

<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