Interruption brutale du client

Bonjour,

On projette d'installer postgreSQL en client/serveur . J'ai regardé la doc, mais je n'ai pas trouvé ce que je cherchais
Je me pose la question suivante:
Si un client est connecte au serveur , et que le client est arrête brutalement
( kill -9 etc ), comment se comporte postgreSQL ?

Le postmaster sur le serveur détruit les processus correspondant au client ?
ou se retrouve-t-on avec des processus zombies ou autre et des connections dans le vide ? autrement , est ce qu'il s'en sort proprement sans corrompre la base ?

Quelqu'un aurait-il experimenté des cas de figures du même type
merci

Salut
Un peu de lectures ici et là...
En fin, ne soit pas étonné de ne pas avoir de réponse! On suppose que...
Du courage!!!!
@+

Je ne vois pas bien le lien avec mon post mais
en fait j'ai fait un essai de principe en faisant des kill -9 brutalement sur les processus postgres de connexion dans différents cas et cela n'a pas eu d'impact a priori

merci d'avoir repondu

Au niveau de la requête , son résultat est sûrement renvoyée au client, qui n'est pas là pour la gérer pas la gérer, tout simplement. J'imagine que les COMMIT éventuels sont exécutés...

Sinon il est possible de définir un timeout sur les requêtes au niveau de la session via l'option
"SET statement_timeout (integer)" (au niveau de la session) ou dans psotgres.conf (global)
http://www.postgresql.org/docs/8.3/s...ig-client.html

(j’ignore si ce paramlètre a une valeur par défaut, la documentation pourrait être plus explciite)

La libraire PHP pour Postgresql permet de définir des connexion persistante avec l'option "pgsql.auto_reset_persistent"
http://php.net/manual/en/pgsql.configuration.php

Il existe un gestionnaire de pool appelé PgBouncer qui permet apparemment de gérer de timeout au niveau de la connexion:
http://wiki.postgresql.org/wiki/PgBouncer
http://pgbouncer.projects.pgfoundry.org/doc/config.html
(voir "Connection sanity checks, timeouts").

Mais je ne crois pas qu'il soit possible de demander à Postgres de détecter un crash d'un client hors le réglage d'une timeout...cela n'est pas vraiment le rôle d'un DBMS, serait compliqué à mettre en œuvre au niveau réseau et risquerait de rendre le système moins réactif.

Un SGBD Relationnel termine toujours ses transactions par un COMMIT (validation) ou un ROLLBACK, même en cas de panne du système (le journal de transaction est là pour ça). Toute requête est une transaction à part entière...
Un KILL de connexion correspond à un ROLLBACK initié par le DBA et non l'utilisateur.

À me lire : http://sqlpro.developpez.com/cours/sqlaz/techniques/

A +