Vous n'êtes pas identifié(e).
Bonjour,
Depuis quelques jours et sans modification de paramètres Postgres ni d'application (mais après un arrêt brutal de notre appplication métier), nous avons beaucoup de "process still waiting for ShareLock on transaction " ou de "Deadlock".
Exemple de log :
2012-05-21 11:02:48 CEST [3872]: [7-1] LOG: process 3872 still waiting for ShareLock on transaction 12371183 after 1000.083 ms
2012-05-21 11:02:48 CEST [3872]: [8-1] CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."t_if_import" x WHERE "id_if_import" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
2012-05-21 11:02:48 CEST [3872]: [9-1] STATEMENT: INSERT INTO t_if_stat (id_if_import, lib_if_stat, phase_stat, metier_stat, type_stat, etiquette_stat, compteur_stat, info_stat, id_if_stat, date_creation) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10)
Premièrement, est ce que cela peut venir de notre version de Postgres 9.1.1 ?
Une mise à jour en 9.1.3 est prévue, mais peut être avancée si le problème est connu en 9.1.1.
Deuxièmement, y a-t-il un moyen de logguer plus d'information sur ces locks ? ou sur les transactions ?
Comment savoir à quoi correspond la transaction 12371183 ?
Car là nous voyons que l'insert est bloqué, mais on ne sait pas par quelle requête il est bloqué...
Il sagirait de trouver des éléments pour régler le problème...
Merci
Hors ligne
Premièrement, est ce que cela peut venir de notre version de Postgres 9.1.1 ?
Une mise à jour en 9.1.3 est prévue, mais peut être avancée si le problème est connu en 9.1.1.
Non, c'est un problème applicatif
Deuxièmement, y a-t-il un moyen de logguer plus d'information sur ces locks ? ou sur les transactions ?
Non, et non. Le message que vous avez là est dû à l'activation du paramètre log_lock_waits. Vous aurez plus d'informations dans le cas d'un deadlock (où les deux requêtes en conflit sont logguées).
Comment savoir à quoi correspond la transaction 12371183 ?
Au moment où ça arrive, vous pouvez regarder le catalogue pg_stat_activity. Filtrer cet identifiant de transaction avec la colonne transactionid, cela vous donnera le pid du processus. À partir de là, quelques requêtes sur pg_lock et pg_stat_activity vous en apprendront plus.
Car là nous voyons que l'insert est bloqué, mais on ne sait pas par quelle requête il est bloqué...
Il sagirait de trouver des éléments pour régler le problème...
Guillaume.
Hors ligne
J'ai en effet trouvé des requêtes sur pg_lock et pg_stat_activity, mais comme le problème n'arrive pas à heure fixe, ce n'est pas évident d'arriver à les exécuter en même temps que le lock...
Bon déjà, je peux dire aux développeurs que le problème n'est pas du tout lié à Postgres !
Hors ligne
