Skip site navigation (1) Skip section navigation (2)

Re: Reponse lente de postgres

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
Subject: Re: Reponse lente de postgres
Date: 2007-08-02 20:30:17
Message-ID: 46B23ED9.60008@lelarge.info (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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

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

In response to

Responses

pgsql-fr-generale by date

Next:From: Hajatiana RAHOLIARIJAONADate: 2007-08-03 07:01:39
Subject: Re: Reponse lente de postgres
Previous:From: Alain LucariDate: 2007-08-02 19:49:19
Subject: Re: Reponse lente de postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group