Vous n'êtes pas identifié(e).
Pages : 1
Re-bonjour...
En regardant mon moniteur de transaction via pgAdmiIII, je vois les choses suivantes :
... PID ... debut de requete blocage requete
00002 2011/02/16 11:56:54 00004 delete from TableTOTO where donnée=2010
00003 2011/02/16 11:56:51 delete from TableTOTO where donnée=2010
00004 2011/02/16 11:56:50 delete from TableTOTO where donnée=2010
Donc une 'contention' entre mon PID 00002 et 0004 QUI BLOQUE les 3 'delete'... Cette situation a duré quelques minutes avant de se décanter => ok
Quand je regarde les verrous, je vois, dans la pid qui a bloqué '00004', des lignes qui s'accumulent avec des choses comme : ExclusiveLock, suivis de Roweclusivelock, accessSharelock etc...
Moi qui croyait que postgrès ne bloquait pas les lignes mise à jour, je suis un peu perplexe...
Pouvez-vous m'expliquer le role de ces différents locks ?
Merci d'avance...
PS : Quelle est le lien entre la 'relation' et le 'PID' ?
Hors ligne
PostgreSQL ne bloque pas les lignes mises à jour… pour les lecteurs (SELECT). C'est à dire que les lecteurs ne bloquent pas les écrivains, les écrivains ne bloquent pas les lecteurs, et les lecteurs ne se bloquent pas entre eux.
Par contre, les écrivains, si ils veulent modifier la même donnée, se bloquent entre eux (et c'est heureux).
Donc si 3 delete ont été lancés comme là, à quelques secondes d'intervalle, les 00003 et 00004 voient encore les enregistrements de TableTOTO (00002 n'a pas encore commité). Eux aussi veulent donc effacer les enregistrements correspondant à la clause where. Mais ils doivent attendre de savoir si 00002 commit (dans ce cas là, les enregistrements ne sont plus visibles pour eux) ou rollback (dans ce cas là, c'est à eux de faire le travail).
Regardez le chapitre MVCC de la doc PostgreSQL, il explique tout ça très clairement: http://docs.postgresql.fr/9.0/mvcc.html
Marc.
Hors ligne
Le PID c'est l'identifiant du processus système qui traite la requête. Tu peux retrouver la listes des processus avec la commande "ps -u postgres" (sous linux)
Il est possible de provoquer un ROLLBACK sur une transaction donnée en utilisant le PID . Par exemple si veut annuler le premier DELETE pour laisser passer les autres, il suffit de taper la requête SQL suivante :
SELECT pg_cancel_backend('00002');damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Il n'y a pas vraiment de lien entre la 'relation' et le 'pid'. Une relation, c'est le terme de l'algèbre relationnelle. On appelle ça une table en SQL. En interne, PostgreSQL utilise des termes de l'algèbre relationnelle, c'est un peu déroutant quand on n'en a pas l'habitude.
Marc.
Hors ligne
Pages : 1