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:

PQisthreadsafe

Returns the thread safety status of the libpq library.

int PQisthreadsafe();

Returns 1 if the libpq
is thread-safe and 0 if it is not.

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
Section 31.10 or Section 31.12, it's up to you to avoid
concurrent operations on the same PGresult, too.

The deprecated functions PQrequestCancel and PQoidStatus are not thread-safe and should not
be used in multithread programs. PQrequestCancel can be replaced by PQcancel. PQoidStatus can be replaced by PQoidValue.

If you are using Kerberos inside your application (in addition
to inside libpq), you will need
to do locking around Kerberos calls because Kerberos functions
are not thread-safe. See function PQregisterThreadLock in the libpq source code for a way to do
cooperative locking between libpq and your application.

If you experience problems with threaded applications, run the
program in src/tools/thread to see if
your platform has thread-unsafe functions. This program is run by
configure, but for binary distributions
your library might not match the library used to build the
binaries.