Requêtes bloquées plus d'une journée sur postgresql

Bonjour,

J’ai une DB heroku qui est pas mal chargée (notamment avec beaucoup de produits/variations, on compte en millions de lignes). Et parfois elle "s’emballe" et des requêtes restent bloquées jusqu’à 1jour (ou + ?) en "active".

Lorsque je kill ces requests ça résoud le pb. Mais comment est-ce qu’on peut en arriver là ?! C’est souvent des requêtes un peu bête genre des COUNT()… J’ai lu un peu partout qu’il n’était pas recommandé de forcer un statement_timeout mais j’ai bien envie de faire ça vu les problèmes.

Est-ce que vous avez déjà eu des cas similaires ?

Très probablement des LOCKS. Tu as une requête lancée à l’instant T qui modifie le contenu de tes tables, et une autre qui fait un simple SELECT. Tant que la requête en écriture n’a pas fini son job, l’autre est bloquée. (je carricature peut-être un peu ; a priori, il faut 2 requêtes qui se bloquent mutuellement)

Ou un utilisateur qui a lancé une requête, mais il n’a pas fait ni commit, ni rollback. La BDD sait qu’il y a quelque chose en suspens, et elle attend.

Je pense que dans les outils d’admin de PG (dans PGADMIN), tu peux consulter les LOCKs.

Y’a pas de timeout sur les requêtes dans des transactions non terminées ? En tous les cas elles devraient avoir le statut idle in transaction et pas active donc elles ne me concernent pas.

Cependant c’est vrai que les locks ça peut être ça… Mais 24h de lock pour des count ?

Pour ce qui est de pgadmin j’ai pas d’accès, et je ne sais pas trop quoi regarder à part le fameux SELECT * FROM pg_stat_activity WHERE state = 'active'.

Tu dis 24h de lock, mais en fait c’est potentiellement beaucoup plus. C’est '’seulement’' 24h, parce que tu fais une action pour débloquer la situation.

Tu es comme dans une situation où 2 voitures sont face à face dans une rue étroite, et aucun des 2 conducteurs n’accepte de reculer pour débloquer la situation. Avec des humains, ça finit par se débloquer, mais ici, ça peut rester bloqué une éternité.

La prochaine fois que ça se produit, regarde toutes les sessions actives, tu verras probablement une autre session qui a une durée anormalement longue.

Techniquement je fais du PHP donc mes sessions vont toujours die à un moment. PostgreSQL va garder les requêtes anyway ? Weird non ?

Et puis, le lock c’est une chose, mais normalement un lock c’est en attente d’autre chose. Ça sous entends que c’est supposé se dérouler au fil du temps et pas empirer. (je parle de genre 10 requêtes de count bloquantes sur une table qui fait quelques millions de lignes, c’est pas fou) En plus du lock sur un select c’est quand même tout à fait étrange.

J’ai vu que le paramètre lock_timeout existe mais n’est pas activé par défaut. La prochaine fois que ça se produit je vais voir si je peux déterminer si c’est vraiment des locks.