Forums PostgreSQL.fr

tsn77130

Membre

statement_timeout

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)

rjuju

Administrateur

Re : statement_timeout

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/

tsn77130

Membre

Re : statement_timeout

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 ?

rjuju

Administrateur

Re : statement_timeout

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/

tsn77130

Membre

Re : statement_timeout

J'ai revérifié, c'est bien les mêmes infos de connexion

rjuju

Administrateur

Re : statement_timeout

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/

gleu

Administrateur

Re : statement_timeout

Rien n'empêche l'utilisateur de faire un "SET statement_timeout TO 0" dans sa session...

---

Guillaume.

tsn77130

Membre

Re : statement_timeout

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)

rjuju

Administrateur

Re : statement_timeout

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/

tsn77130

Membre

Re : statement_timeout

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é.

tsn77130

Membre

Re : statement_timeout

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 ...