32.20. Behavior in Threaded Programs#
As of version 17,libpq is always reentrant and thread-safe. However, one restriction is that no two threads attempt to manipulate the samePGconn 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 thePGresult-modifying functions described inSection 32.12 orSection 32.14, it's up to you to avoid concurrent operations on the samePGresult, too.
In earlier versions,libpq could be compiled with or without thread support, depending on compiler options. This function allows the querying oflibpq's thread-safe status:
PQisthreadsafe#Returns the thread safety status of thelibpq library.
int PQisthreadsafe();
Returns 1 if thelibpq is thread-safe and 0 if it is not. Always returns 1 on version 17 and above.
The deprecated functionsPQrequestCancel andPQoidStatus are not thread-safe and should not be used in multithread programs.PQrequestCancel can be replaced byPQcancelBlocking.PQoidStatus can be replaced byPQoidValue.
If you are using Kerberos inside your application (in addition to insidelibpq), you will need to do locking around Kerberos calls because Kerberos functions are not thread-safe. See functionPQregisterThreadLock in thelibpq source code for a way to do cooperative locking betweenlibpq and your application.