32.21. 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.
Similarly, if you are usingCurl inside your application,and you do not alreadyinitialize libcurl globally before starting new threads, you will need to cooperatively lock (again viaPQregisterThreadLock) around any code that may initialize libcurl. This restriction is lifted for more recent versions ofCurl that are built to support thread-safe initialization; those builds can be identified by the advertisement of athreadsafe feature in their version metadata.