donmage a tout à fait raison - LISTEN et NOTIFY sont ce que vous voulez. Vous aurez toujours besoin d'une boucle d'interrogation, mais elle est très légère et n'entraînera pas de charge détectable du serveur.
Si vous voulez psycopg2 pour déclencher des rappels à tout moment dans votre programme, vous pouvez le faire en créant un thread et en faisant en sorte que ce thread exécute la boucle d'interrogation. Vérifiez si psycopg2 applique l'accès à la connexion thread-safe ; si ce n'est pas le cas, vous devrez effectuer votre propre verrouillage afin que votre boucle d'interrogation ne s'exécute que lorsque la connexion est inactive et qu'aucune autre requête n'interrompe un cycle d'interrogation. Ou vous pouvez simplement utiliser une deuxième connexion pour votre interrogation d'événement.
Dans tous les cas, lorsque le thread d'arrière-plan qui interroge les événements de notification en reçoit un, il peut invoquer une fonction de rappel Python fournie par votre programme principal, qui peut modifier les structures de données/variables partagées par le reste du programme. Attention, si vous faites cela, cela peut vite devenir un cauchemar à entretenir.
Si vous adoptez cette approche, je vous suggère fortement d'utiliser le multithreading / multiprocessing modules. Ils vous faciliteront énormément la vie, en fournissant des moyens simples d'échanger des données entre les threads et en limitant les modifications apportées par le thread d'écoute à des emplacements simples et bien contrôlés.
Si vous utilisez des threads au lieu de processus, il est important de comprendre qu'en cPython (c'est-à-dire "Python normal"), vous ne pouvez pas avoir une véritable interruption de rappel, car un seul thread peut s'exécuter en cPython à la fois. Lisez à propos du "verrouillage global de l'interpréteur" (GIL) pour en savoir plus à ce sujet. En raison de cette limitation (et de la nature plus simple et plus sûre de la simultanéité sans partage par défaut), je préfère souvent le multitraitement au multithreading.
