libpq est réentrante et sûre avec les threads par défaut. Vous pourriez avoir besoin d'utiliser des options de compilation supplémentaires en ligne lorsque vous compiler le code de votre application. Référez-vous aux documentations de votre système pour savoir comment construire des applications actives au niveau thread ou recherchez PTHREAD_CFLAGS et PTHREAD_LIBS dans src/Makefile.global. Cette fonction permet d'exécuter des requêtes sur le statut de libpq concernant les threads :

Une restriction : il ne doit pas y avoir deux tentatives de threads manipulant le même objet PGconn à la fois. En particulier, vous ne pouvez pas lancer des commandes concurrentes à partir de 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 en lecture seule après leur création et, du coup, ils peuvent être passés librement entre les threads. Les objets PGresult sont en lecture seule après leur création et, du coup, ils peuvent être passés librement entre les threads. Néanmoins, si vous utilisez une des fonctions de modification d'un PGresult décrites dans Section 33.11 ou Section 33.13, vous devez aussi éviter toute opération concurrente 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 multithread. PQrequestCancel peut être remplacé par PQcancel. PQoidStatus peut être remplacé par PQoidValue.

Si vous utilisez Kerberos avec votre application (ainsi que dans libpq), vous aurez besoin de verrouiller les appels Kerberos car les fonctions Kerberos ne sont pas sûres lorsqu'elles sont utilisées avec des threads. Voir la fonction PQregisterThreadLock dans le code source de libpq pour récupérer un moyen de faire un verrouillage coopératif entre libpq et votre application.