libpq est réentrante et compatible avec les threads par défaut. Vous pourriez avoir besoin d'utiliser des options de compilation supplémentaires en ligne lorsque vous compilez le code de votre application. Référez-vous à la documentation de votre système pour savoir comment construire des applications avec threads ou recherchez PTHREAD_CFLAGS et PTHREAD_LIBS dans src/Makefile.global. Cette fonction permet d'interroger le statut de compatibilité de libpq avec les threads :

Une restriction : il ne doit pas y avoir deux threads manipulant le même objet PGconn à la fois. En particulier, vous ne pouvez pas lancer des commandes concurrentes depuis des threads différents à travers le même objet de connexion (si vous avez besoin de lancer des commandes concurrentes, utilisez plusieurs connexions).

Les objets PGresult sont normalement en lecture seule après leur création et, du coup, peuvent être passés librement entre les threads. Néanmoins, si vous utilisez une des fonctions décrites dans Section 33.11 ou Section 33.13 qui modifient PGresult, il est de votre responsabilité d'éviter des opérations concurrentes sur le même PGresult.

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 PQcancel . 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.