Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Une petite question plutôt destinée à Guillaume. Y-a-t-il un timeout lors d'une requête exécutée via PgAdmin (1.8.4 Windows)? Je n'ai rien trouvé dans les préférences et rien non plus côté base dans le postgresql.conf. A l'origine de cette interrogation, j'ai lancé une requête d'alimentation de table et machinalement rafraîchis les données. Malheureusement, un produit cartésien a fait que la requête bouclait à l'infini. Trop tard, les fenêtres de pgAdmin se sont figées et plus moyen d'en sortir. La seule solution a été de détruire le process, laissant bloquée du même coup la table avec impossibilité d'y accéder ou de la détruire ultérieurement.
J'ai pu tout de même annuler la transaction et retrouver mon petit monde 
Hors ligne
Y-a-t-il un timeout lors d'une requête exécutée via PgAdmin (1.8.4 Windows)?
Non.
La seule solution a été de détruire le process, laissant bloquée du même coup la table avec impossibilité d'y accéder ou de la détruire ultérieurement.
Dans ce cas, il y a eu destruction du processus client, et non pas du processus serveur. En effet, si le processus client est dégagé non proprement, le processus serveur peut mettre un certain temps pour s'en rendre compte.
Pour en revenir au problème initial, il pourrait être intéressant de pouvoir indiquer un délai maximum. Dans ce cas, pgAdmin ajouterait un statement_timeout avant de lancer la requête et il reviendrait à la valeur précédente après. L'idée est intéressante. Si cette implémentation convient, je pourrais même y jeter un œil rapidement 
Guillaume.
Hors ligne
Whoua! Merci Guillaume pour cette réponse fulgurante. Je me doutais bien que non, mais avec l'idée que cela pourrait intéresser. Rien de bien méchant effectivement, mais quand on doit recommencer de configurer l' environnement précédent avec une dizaine de fenêtres 
Hors ligne
Ajouté dans ma TODO list.
Guillaume.
Hors ligne
Bon, j'ai fait le patch hier soir, entre deux baillements (c'est plutôt intensif au boulot actuellement). Je l'ai envoyé ce matin sur la liste hackers de pgAdmin et il s'en est suivi toute une discussion. Il serait intéressant d'y jeter un œil pour donner ton avis. Voici le lien vers le thread : http://archives.postgresql.org/pgadmin- … g00035.php
Pour information, il est possible d'avoir un temps limite d'exécution d'une requête grâce au paramètre statement_timeout. Ce paramètre peut même être configuré dans la session (ce que fait mon patch d'ailleurs). Tu peux donc avoir une macro qui la exécute cette requête (SET statement_timeout TO '1s' par exemple), ou de le configurer sur l'utilisateur (ALTER USER le_user SET statement_timeout TO '1s'... attention, dans ce cas, chaque requête exécutée par cet utilisateur, même sans passer par pgAdmin, aura cette configuration, ce qui peut être gênant).
Sinon je suis à l'écoute de toute amélioration possible de ce patch
Guillaume.
Hors ligne
Bonjour Guillaume,
Je ne m'attendais pas à tant de réactivité 
Pour ma part, je pense que la configuration par session est parfaite, cela correspond à un besoin à un moment donné. Le ALTER USER me semble plus risqué, mais diablement tentant? Cela fonctionne-t-il dans le cas d'un trigger rebouclant sur lui-même? Y-a-t-il un message d'erreur (capturé par une exception?) avec l'abandon de la transaction en cause?
Je suis bien conscient que l'on ne peut pas inclure tous les paramètres possibles et imaginables, néanmoins ne pas planter bêtement son environnement de développement me semblait intéressant. Dans tous les cas , un grand merci.
Hors ligne
Cela fonctionne-t-il dans le cas d'un trigger rebouclant sur lui-même?
Oui.
Y-a-t-il un message d'erreur (capturé par une exception?) avec l'abandon de la transaction en cause?
Il y a ROLLBACK et message d'erreur. Un exemple rapide :
guillaume@laptop:~/freeprojects/git.pgadmin$ psql base1
psql (8.5devel)
Saisissez « help » pour l'aide.
base1=# set statement_timeout to '1ms';
SET
base1=# select i from generate_series(1, 1000) as i;
ERREUR: annulation de la requête à cause du délai écoulé pour l'exécution de l'instruction
base1=# set lc_messages to 'C';
SET
base1=# select i from generate_series(1, 1000) as i;
ERROR: canceling statement due to statement timeoutGuillaume.
Hors ligne
J'en ai maintenant la preuve, le Paradis existe 
Hors ligne
Pages : 1