Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai besoins de votre aide pour dépasser ce problème d'interblocage des transactions qui m'arrive tous les jours, malgré que j'ai fait le minimum des transactions explicites (BEGIN).
La deuxième requête est mise dans une transaction (32122), mais la première 28786 n'est pas dans une transaction, et je m'assure avant de la lancer, que la tables n'est bloquée par une transaction via la requête suivante :
select count(*) nbr from pg_class JOIN pg_locks on pg_class.oid = relation and relname = '" . $tb . "'
comment donc ce blocage peut il arrivé ?
Est ce que c'est lié au problème des statistiques mentionné dans le log ?
Comment je peux aussi, résoudre le problème du collecteur de statistiques ?
################ VOICI UNE PARTIE DE NOTRE LOG #################
LOG: utilise de vieilles statistiques à la place des actuelles car le collecteur de statistiques ne répond pas
LOG: utilise de vieilles statistiques à la place des actuelles car le collecteur de statistiques ne répond pas
ERREUR: Bloquage mortel détecté
DÉTAIL: Le processus 28786 attend ShareLock sur transaction 2608329 ; bloqué par le processus 32122.
Le processus 32122 attend ShareLock sur transaction 2608293 ; bloqué par le processus 28786.
Processus 28786 : UPDATE data_alltime SET j11 = 0
Processus 32122 : UPDATE data_alltime SET j10 = j10 + 50000, m13 = m13 + 50000, a5 = a5 + 50000 WHERE id= 4724
ASTUCE : Voir les journaux applicatifs du serveur pour les détails sur la requête.
INSTRUCTION : UPDATE data_alltime SET j11 = 0
LOG: utilise de vieilles statistiques à la place des actuelles car le collecteur de statistiques ne répond pas
LOG: utilise de vieilles statistiques à la place des actuelles car le collecteur de statistiques ne répond pas
LOG: utilise de vieilles statistiques à la place des actuelles car le collecteur de statistiques ne répond pas
#####################################################################
Hors ligne
Les verrous sont sur des lignes, donc vous ne pouvez pas les voir avec pg_locks.
Comment savez-vous que le processus 28786 n'est pas dans une transaction ? Qu'a fait le processus 32122 avant l'UPDATE ?
Mon impression est que le processus 32122 a fait un UPDATE avant le processus 28786 qui a verrouillé une ligne pour laquelle j11=0, ce qui a bloqué le processus 28786 dans son attente du verrou sur la ligne. Le processus 32122 a essayé de faire une nouvelle mise à jour pour les lignes id=47241, et une de ces lignes doit avoir j11=0, ce qui a bloqué le processus 32122 en attente du résultat de la requête du processus 28786. Du coup, les deux sont en attente de la fin de l'autre, situation classique du deadlock.
Quant au collecteur de statistiques, il n'y est pour rien. Cela indique seulement que votre système est surchargé, notamment au niveau des IO.
Guillaume.
Hors ligne
Merci pour votre réponse,
J'ai deux scriptes qui tourne en parallèle et touchent les mêmes tables.
L'un d'eux utilise des transactions (BEGIN) et l'autre n'a pas.
Les tables touchées dans la transaction (BEGIN) sont bien présentent dans pg_locks et j'essaye de les évitées par le deuxième script tant qu'elles ne sont pas libres (boucle).
Comment savez-vous que le processus 28786 n'est pas dans une transaction ? .
Le deuxième process 28786 ne lance que des updates simples sans ouvrir une transaction, on sait que postgres ouvre des transaction implicite pour chacune.
Hors ligne
Pages : 1
