À partir de la version 17, libpq est toujours ré-entrante et accepte les threads. Néanmoins, il existe une restriction : deux threads ne peuvent pas manipuler le même objet PGconn en même temps. En particulier, vous ne pouvez pas laiser des commandes concurrentes à partir de différents threads via le même objet de connexion. (Si vous avez besoin de le faire, utilisez plusieurs connections.)

Les objets PGresult sont normalement en lecture seule après leur création et peuvent donc être passés librement entre les threads. Néanmoins, si vous utilisez une des fonctions de modification d'un objet PGresult décrites ans Section 32.12 ou Section 32.14, vous devez aussi éviter les opérations concurrentes sur le même objet PGresult.

Dans les versions précédentes, libpq devait être compilé avec ou sans support des threads, suivant les options du compilateur. Cette fonction permet le requêtage du statut sur les threads de la libpq :

Les fonctions obsolètes PQrequestCancel et PQoidStatus ne gèrent pas les threads et ne devraient pas être utilisées dans des programmes multithreads. PQrequestCancel peut être remplacé par PQcancelBlocking. PQoidStatus peut être remplacé par PQoidValue.

Si vous utilisez Kerberos avec votre application (en plus de libpq), vous aurez besoin de verrouiller les appels Kerberos car les fonctions Kerberos ne supportent pas les threads. Voir la fonction PQregisterThreadLock dans le code source de libpq sur comment faire un verrouillage coopératif entre libpq et votre application.