27.14. Comportement des programmes threadés

libpq est réentrante et sûre avec les threads si l'option en ligne de commande de configure, --enable-thread-safety, a été utilisée lors de la construction de PostgreSQL. De plus, 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.

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 fonctions obsolètes PQrequestCancel, PQoidStatus et fe_setauthsvc 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. Il n'existe pas aucune bonne raison pour appeler fe_setauthsvc.

Les applications libpq qui utilisent la méthode d'authentification crypt sont liés à la fonction crypt() du système d'exploitation, qui est souvent non conforme avec les threads. Il est mieux d'utiliser la méthode md5, qui est compatible avec les threads sur toutes les plateformes.

Si vous expérimentez des problèmes avec les applications utilisant des threads, lancez le programme dans src/tools/thread pour voir si votre plateforme à des fonctions non compatibles avec les threads. Ce programme est lancé par configure mais, dans le cas des distributions binaires, votre bibliothèque pourrait ne pas correspondre à la bibliothèque utilisée pour construire les binaires.