Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai sur la ma base une contrainte user statement_timeout limitée à 1800000 (30mns) pour un compte donné.
Normalement, lorsque ce compte effectue une requête > à 30 mns, elle est killée par postgres.
hors, hier soir, j'ai une requete de cet user qui a duré plus de 15 heures, mettant par la même occasion le bazar sur ma base.
Avez vous une idée de pourquoi ma requête n'a pas été arrêtée par postgres cette fois ?
Merci d'avance !
Dernière modification par tsn77130 (27/08/2014 11:46:30)
Hors ligne
Quelle est la définition exacte de ce paramètre ? Avez-vous vérifié qu'il n'a pas été supprimé ?
Julien.
https://rjuju.github.io/
Hors ligne
Merci de la réponse rjuju
Il est toujours la, défini comme ceci :
ALTER ROLE techs SET statement_timeout = '1500000';
Après recherches, je me suis aperçu que postgres killait bien les requêtes avec la mention explicite "ERROR: canceling statement due to statement timeout", SAUF lorsque cette requête est lancée depuis un client PGADMIN !! (la même requête, lancée depuis la même machine via psql avec les mêmes identifiants de connexion est bien killée
Des idées ?
Hors ligne
La connexion depuis pgAdmin doit se faire avec un autre utilisateur ou sur la mauvaise base, sinon la requête serait bien annulée.
Julien.
https://rjuju.github.io/
Hors ligne
J'ai revérifié, c'est bien les mêmes infos de connexion 
Hors ligne
Je viens de tester avec pgAdmin 1.18 et postgresql 9.2, le statement_timeout sur un utilisateur est bien pris en compte. Il n'y a pas de raison qu'il en soit autrement.
Julien.
https://rjuju.github.io/
Hors ligne
Rien n'empêche l'utilisateur de faire un "SET statement_timeout TO 0" dans sa session...
Guillaume.
Hors ligne
Nouveaux tests effectués, je n'y comprend rien.
J'ai mis le même statement sur une autre base d'un autre serveur, il est bien pris en compte par pgadmin.
Par contre, sur mon serveur 'principal', rien n'y fait, il n'en tient pas compte.
Mes 2 serveurs sont en 9.3 , pgadmin 1.18.1
Meme le "set statement_timeout to '2000'; " n'est pas pris en compte via pgadmin (ca fonctionne bien via psql), alors que sur ma seconde base, il fonctionne parfaitement...
D'ailleurs, une même requête n'a pas le même temps de réponse via psql ou pgadmin (1s en psql, environ 40 !! via pgadmin)
Pourtant, je suis bien sur que c'est la même base, et le même compte.
Y a il des éléments de conf de pgadmin qui pourraient interférer ?
Dernière modification par tsn77130 (28/08/2014 10:13:08)
Hors ligne
Si vous exécutez dans pgAdmin :
set statement_timeout to 1000;
select * from pg_sleep(2)le paramètre ne sera pas pris en compte. Par contre effectuer ces deux requêtes à la suite, cela sera bien pris en compte.
Pour le problème de temps d'exécution différent, soit les 39 secondes sont le temps que met pgAdmin à afficher les données, wxWidget n'étant pas des plus véloces (peu probable), soit il ne s'agit pas du bon serveur et les données sont différentes.
Julien.
https://rjuju.github.io/
Hors ligne
Effectivement, lorsque je lance un "select * from pg_sleep(2)" après avoir validé "set statement_timeout to 1000;", j'ai bien un statement timeout.
Par contre, si je lance un "select * from users;", ma requete n'est pas stoppée.
Comment cela se fait il ?
Pour la base, j'ai un autre utilisateur qui arrive au même résultat, 1s en psql , et 40s en pgadmin.
Pour info, j'étais en 9.3.4 ce matin, j'ai monté le serveur en 9.3.5, rien n'a changé.
Hors ligne
Le temsp de réponse est vraiment lié a ce serveur, tout comme le fait que le statement timeout ne fonctionne pas, car sur mon autre serveur j'ai ma réponse en 1s dans pgadmin, et ma requete est bien stoppée par timeout_statement ...
Hors ligne
Pages : 1