Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'essaye de faire deux updates paralléle sur la même table, j'ai bien évidamment un problème avec les lock.
psql:ag_update_c4.sql:2132: ERROR: deadlock detected
DETAIL: Process 21448 waits for ShareLock on transaction 8105608; blocked by process 21447.
Process 21447 waits for ShareLock on transaction 8105610; blocked by process 21448.
HINT: See server log for query details.
ROLLBACK
.Quelequ'un sait comment faire pour executer convenablement mes deux ubdates.
Je note que pour chaque update, je suis obligatoirement en single transaction.
Je suis sur la 9.1.
Cordialement
Hors ligne
Bonjour,
il nous faudrait un peu plus de détail sur les requêtes update pour pouvoir vous aider.
Le plus simple serait bien évidemment de faire les updates consécutivement.
Julien.
https://rjuju.github.io/
Hors ligne
Update table A
SET A.a = 1
WHERE 0 <= id < 1000;
Update table A
SET A.b = 1
WHERE 0 <= id < 1000;
Dernière modification par Postgres.0 (03/07/2012 10:29:10)
Hors ligne
Drôle d'idée.
Pourquoi ne le faites-vous pas avec 1 seul ordre SQL?
Hors ligne
D'accord avec flo. Autre chose, même si ça peut être une typo, le ; avant le WHERE est à supprimer.
Guillaume.
Hors ligne
je dois executer deux transaction en parallèle.
Ces transactions insèrent dans des tables differentes (B et C).
A la fin de chanque transaction , je dois taguer des lignes d'une meme table.
Ce tague veut dire que les lignes de la table A ont été bien insérées
Hors ligne
Oui le ";" est une erreur de frappe.
Ces deux updates sont chacun dans un fichier et chacun est suivi d'un "commit".
Manque de bole, ils update en meme temps les memes lignes de la table A.
Hors ligne
Je connais pas bien les LOCK et compagnie.
Mais y a pas quelque chose genre LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE qui me permet de faire ces taches correctement.
Hors ligne
Si, il existe une commande de ce type. Excellent pour bloquer tout le monde et donc descendre les performances.
Il est préférable que ce soit le même processus qui fassent ces deux UPDATE. Ou alors il faut tout un mécanisme pour éviter qu'ils mettent à jour les mêmes lignes. Car le problème n'est pas qu'ils mettent à jour la même table mais les mêmes lignes.
Guillaume.
Hors ligne
Il me semble que dans vos traitements, vous partez de la table A pour créer des enregistrements dans des tables B et C (à partir des données de A, donc).
Les 2 transactions sont en parallèle : pourquoi?
Et une fois les lignes créées, on met des indicateurs dans la table A pour signifier que les lignes ont été traitées.
Si c'est bien cela, il y a un problème de conception générale. Il faudrait faire les écritures dans B et C l'une après l'autre.
Ou si vous voulez paralléliser les écritures, trouver un critère qui permette de distinguer les lignes de la table A pour les traiter en parallèle, mais chaque traitement se fera sur des ensembles disjoints de lignes de la table A. Par contre les écritures dans B et C seraient en séquence.
Hors ligne
flo:
les transactions sont parallèles pour des raisons de perfs.
Hors ligne
C'est donc bien ce que je pensais : la parallélisation n'est pas faite suivant les bons critères.
Il vaudrait mieux paralléliser suivant les lignes de la table A. Comme cela, pas de mises à jour concurrentes entre les transactions, et pas besoin de faire des locks qui rendraient la parallélisation inutiles.
En plus, d'un point de vue de développeur, c'est bien plus souple (il est facile de changer le critère de découpage des lignes de A, voire supprimer la parallélisation si cela s'avère plus efficace au final).
Au passage, A, B et C sont bien dans la même base?
Hors ligne
on ne peut pas paralléliser suivant les lignes de la table A, les deux process doivent chacun lire toutes les lignes de cette table.
ce que je me demande c'est :
si je faits LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE
1. Est-ce-que une autre transaction peut écrire dans la table A.
2. Est-ce-que une autre transaction peut lire les lignes de la table A
3. est-ce-que toute la table est verouillée ou bien seules les lignes updatées par ma transaction sont verouillées.
4. En quoi les perfs sont impactées (exemple????).
Hors ligne
on ne peut pas paralléliser suivant les lignes de la table A, les deux process doivent chacun lire toutes les lignes de cette table.
ce que je me demande c'est :si je faits LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE
1. Est-ce-que une autre transaction peut écrire dans la table A.
D'après http://www.postgresql.org/docs/9.1/stat … PATIBILITY, il semble que non (la modification essaiera d'acquérir un verrou ROW EXCLUSIVE)
2. Est-ce-que une autre transaction peut lire les lignes de la table A
oui
3. est-ce-que toute la table est verouillée ou bien seules les lignes updatées par ma transaction sont verouillées.
Toute la table
4. En quoi les perfs sont impactées (exemple????).
Simplement, vu que le verrou posé par la 1ère transaction est incompatible avec une modification, il faudra que la 2ème transaction attende la fin du traitement (le COMMIT ou le ROLLBACK) de la 1ère pour pouvoir mettre à jour la table A.
De toute manière, vu que vous travaillez sur les mêmes lignes, il n'y a pas de solution qui permette de paralléliser les mises à jour sur la table A.
D'où ma proposition de modifier la conception...
Hors ligne
Merci beaucoup,
j'ai opté finalement pour des écritures sequentielles.
Dernière modification par Postgres.0 (04/07/2012 10:12:55)
Hors ligne
Pages : 1