Re: Reponse lente de postgres

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

Bonjour,

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: "Alain Lucari" <eurlix(dot)alain(at)free(dot)fr>
Cc: <pgsql-fr-generale(at)postgresql(dot)org>
Sent: Thursday, August 02, 2007 11:30 PM
Subject: Re: [pgsql-fr-generale] Reponse lente de postgres


> Bonsoir,
>
> Alain Lucari a écrit :
> > > >    Nous avons constaté que : BEGIN TRANSACTION pose un verouillage
> > > > exclusif de la table. Est ce normal.
> > > Un BEGIN ne pose aucun verrou. Par contre, vous avez une ligne
> > > supplémentaire dans pg_locks indiquant l'ID de transaction.
> >
> > et si on ne termine pas par un COMMIT, l'ensemble de la transaction
> > depuis le begin n'est pas pris en compte, NON ?
>
> Une transaction n'est validée que par l'ordre SQL COMMIT (ou END). Une
> transaction est annulée dans les autres cas : une requête qui échoue, un
> ordre ROLLBACK, une fin de session.
>
> > a priori, la seule façon de locker une table est d'écrire
> > explicitement "LOCK nom de table"
>
> Si on veut verrouiller la table, oui, c'est le seul moyen. Un mauvais
> moyen, mais le seul moyen.
>
> > > Au prochain SELECT, INSERT, UPDATE ou DELETE, un verrou sera posé
> > > sur une table, mais ce verrou n'est pas forcément exclusif.
> >
> > sauf si on a écrit "SELECT FOR UPDATE", NON ?
>
> Ce n'est pas un verrou exclusif. Le verrou posé est un RowShareLock.
> Vous pouvez donc lire la table, la ligne. Vous pouvez aussi insérer des
> lignes dans cette table. Seule action impossible : une mise à jour de la
> même ligne (ou des mêmes lignes). Sinon, vous aurez ce résultat :
>
> guillaume(at)laptop:~$ ps -ef | grep postgres
> 1000     16183 22198  0 22:22 ?        00:00:00 postgres: guillaume pgfr
> [local] idle in transaction
> 1000     16187 22198  0 22:22 ?        00:00:00 postgres: guillaume pgfr
> [local] UPDATE waiting

C'est bien le phenomene qui se produisit. Des listes de waiting comme : 
UPDATE waiting; LOCK table waiting.

Je m'explique un peu :
Un ou plusieurs utilsateurs inserent des données dans trois tables 
differentes (ce sont les préparateurs), une operation compte environ 2000 à 
2500 lignes(environ 50 à 60.000 lignes /jour) . Ces données seront ensuite 
utilisé et updatés par l'ensemble de production.
Le pb se maifeste quand les préparateurs inserent ses données et en même 
temps la production met à jour dans les tables d'insertion.
Les insertions debutent par un BEGIN TRANSACTION et se termine par COMMIT ou 
ROLLBACK s'il y a erreur.

C'est pourquoi je me demande si les tables entieres sont verouillés ou il y 
a un nombre limite de UPDATE quand on fait des insertions.
Le verouillage au niveau de la production est "SELECT for update".

> Un processus en transaction (là il ne fait rien mais il pourrait
> travailler, ça ne changerait rien au processus suivant) et un processus
> en attente (UPDATE waiting).
>
> En fait, vous avez simplement avancé le verrou de l'UPDATE au moment du
> SELECT.
>
> > si NON, cela pourrait expliquer quelques problèmes que j'ai eu, en 7.
> >
> > > > En lancant la transaction, nous ne pouvons plus faire des UPDATE
> > > > sur la table et tous les requettes sont mis en attente.
> > > On pourrait voir le contenu de la transaction ?
> >
> > Ben OUI, ce serait plus simple.
> > > > Avez vous une idée ou me donnér une commande qui ne verouille pas
> > > > la table entier?
> > > Il n'existe pas de verrou de lignes sur PostgreSQL (en dehors du
> > > module contrib userlock et des advisory locks en 8.2).
> > select for UPDATE pas en 8 ?
>
> Si si, j'ai d'ailleurs déjà renvoyé un message pour expliquer mon erreur.
>
>
> --
> Guillaume.
> <!-- http://abs.traduc.org/
>     http://lfs.traduc.org/
>     http://docs.postgresqlfr.org/ -->
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings