Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous avons des segmentations faults plus fréquents depuis notre monté de version sur une postgres 15 on dirait (2 en 4 mois).
Pour la dernière nous avons seulement cela dans les logs:
2023-09-15 14:55:18 UTC [1969]: [36-1] user=,db= LOG: server process (PID 3361221) was terminated by signal 11: Segmentation fault
2023-09-15 14:55:18 UTC [1969]: [37-1] user=,db= DETAIL: Failed process was running: FETCH ALL IN "<unnamed portal 4>"
2023-09-15 14:55:18 UTC [1969]: [38-1] user=,db= LOG: terminating any other active server processes
Le FETCH ALL IN d'après ce que j'ai compris cela veut dire que cela viendrait d'une procédure/ une fonction, c'est cela ?
Comment pouvons nous savoir quelle procédure ou requête a généré ce Segmentation fault ?
Sur les logs du client qui a généré cette segmentation fault (retrouvé grace au PID) je n'ai pas de dumpstack aucune erreur (pas d'erreur de requête)
En vous remerciant par avance
Bonne journée
Hors ligne
Commencer par désactiver le JIT. Nous avons eu aussi du SEGV, c'était lié au jit.
Hors ligne
Nous avons eu des grosses lenteurs à cause du JIT sur la pg15 nous l'avons donc déjà désactivé.
si je fais show jit
cela réponds off
Hors ligne
Le FETCH ALL IN d'après ce que j'ai compris cela veut dire que cela viendrait d'une procédure/ une fonction, c'est cela ?
Pas forcément, FETCH ALL est une requête SQL. Elle peut simplement faire partie d'une transaction.
Si ça a été exécuté au sein d'une fonction, je ne vois pas comment vous pouvez trouver a posteriori cette fonction. Il faudrait tracer toutes les requêtes pour remonter le fil et encore, vu qu'elle termine en erreur, elle ne sera pas tracée.
Comment pouvons nous savoir quelle procédure ou requête a généré ce Segmentation fault ?
Vous avez déjà la requête, c'est le FETCH ALL, même si j'avoue qu'elle n'aide pas beaucoup.
Sur les logs du client qui a généré cette segmentation fault (retrouvé grace au PID) je n'ai pas de dumpstack aucune erreur (pas d'erreur de requête)
Un peu normal, c'est pas le client qui a planté, mais le processus serveur.
Sans moyen de reproduire l'erreur, il va être très compliqué de corriger ça.
Guillaume.
Hors ligne
merci Guillaume pour vos réponses
Bonne soirée
Hors ligne
Pages : 1
