From: | Alain Lucari <eurlix(dot)alain(at)free(dot)fr> |
---|---|
To: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: Reponse lente de postgres |
Date: | 2007-08-02 19:49:19 |
Message-ID: | 20070802214919.1c3553ca.eurlix.alain@free.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Bonjour,
Quelques réponses m'intriguent :
Le Thu, 02 Aug 2007 13:54:27 +0200
Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit:
> Hajatiana RAHOLIARIJAONA a écrit :
> > Bonjour,
> >
> > 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 ?
a priori, la seule façon de locker une table est d'écrire
explicitement "LOCK nom de table"
>
> 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 ?
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 ?
>
Cdlt,
--
Alain Lucari (Eurlix)
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2007-08-02 20:30:17 | Re: Reponse lente de postgres |
Previous Message | Guillaume Lelarge | 2007-08-02 12:50:24 | Re: Reponse lente de postgres |