Re: Reponse lente de postgres

["Hajatiana RAHOLIARIJAONA" <administrateur(at)saisie(dot)mg>]

Bonjour,

   Nous avons constaté que : BEGIN TRANSACTION pose un verouillage exclusif 
de la table. Est ce normal.

En lancant la transaction, nous ne pouvons plus faire des UPDATE sur la 
table et tous les requettes sont mis en attente.

Avez vous une idée ou me donnér une commande qui ne verouille pas la table 
entier?

Cordialement,



Hajatiana RAHOLIARIJAONA Administrateur réseaux et systèmes du centre de 
traitement SAISIE.MG administrateur(at)saisie(dot)mg
----- Original Message ----- 
From: "Guillaume Lelarge" <guillaume(at)lelarge(dot)info>
To: "Hajatiana RAHOLIARIJAONA" <administrateur(at)saisie(dot)mg>
Cc: "Jean-Paul Argudo" <jean-paul(at)argudo(dot)org>; 
<pgsql-fr-generale(at)postgresql(dot)org>
Sent: Tuesday, July 31, 2007 10:03 AM
Subject: Re: [pgsql-fr-generale] Reponse lente de postgres


> Hajatiana RAHOLIARIJAONA a écrit :
> > Je suis bloqué actuellement, ci après la reponse :
> > procpid | usename | age |        relname         |         mode
> > | granted
> > ---------+---------+-----+------------------------+-----------------------+---------
> >
> >    6110 | prep1   |     | preparation            | AccessShareLock
> > | t
> >    6110 | prep1   |     | preparation            | RowExclusiveLock
> > | t
> >    6110 | prep1   |     | pousse                 | AccessShareLock
> > | t
> >    6110 | prep1   |     | pousse                 | RowExclusiveLock
> > | t
> >    6110 | prep1   |     | preparation_idprep_seq | AccessShareLock
> > | t
> >    6110 | prep1   |     | fichier                | AccessShareLock
> > | t
> >    6110 | prep1   |     | fichier                | RowExclusiveLock
> > | t
> >    6110 | prep1   |     | fichierimage           | AccessShareLock
> > | t
> >    6110 | prep1   |     | fichierimage           | RowExclusiveLock
> > | t
> >    6110 | prep1   |     | pousse_id_seq          | AccessShareLock
> > | t
> >    6110 | prep1   |     | passe                  | AccessShareLock
> > | t
> >    8178 | dg2     |     | pousse                 | ShareRowExclusiveLock
> > | f
> >    8554 | dg15    |     | pousse                 | AccessShareLock
> > | t
>
> Le seul processus bloqué actuellement a le PID 8178. Il attend un verrou
> ShareRowExclusiveLock sur la table pousse. Or pousse a déjà trois
> verrous sur elle : AccessShareLock par le PID 6110 et par le PID 8554,
> et surtout RowExclusiveLock par le 6110. Je pense en voyant ça que je me
> poserais des questions sur le travail réalisé par le 6110 qui détient
> plusieurs verrous sur cinq tables et deux séquences. Pour infos, un
> RowExclusiveLock est demandé pour une mise à jour d'index. Reste à
> savoir pourquoi cet index est mis à jour et pourquoi il met tant de
> temps à se mettre à jour. Utilisez-vous reindexdb par exemple ? l'index
> ne serait-il pas devenu énorme ?
>
>
> --
> Guillaume.
> <!-- http://abs.traduc.org/
>     http://lfs.traduc.org/
>     http://docs.postgresqlfr.org/ -->
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match