Reprise du message précédent :
Histoire d'avancer un peu, z'avez essayé de faire un select sur l'autre table avant le commit pour vérifier que c'était bien cette table qui  lockait?

 
alors, soit deux psql A et B

et A:insert into pomme(..)?

 
attends, y'a moktar qui a demoli la bd a coup de marteaux, jpeux pas essayer de suite

bin bon en virant les contraintes ca bloque pu.
Evidemment, c'est un peu con.

Plus qu'à vérifier les contraintes à la main?

attendre l'avis d'un Pur Expert

bah vu que ce qu'on insert on le récupère avec des select ça devrait rester cohérent, mais ça me troue le cul que les contraintes rendent les requêtes blocantes

etrange, comme deadlock

aaaaahhhhh, fuis, malheureux !

 
pas ca a pas l'air d'etre un deadlock, ca a l'air d'etre fait expres

on m'appelle?
 
Si quelqu'un me fait un résumé je veux bien me pencher sur le problème (j'aime pas les blonde aux gros seins )

 
alors
On a une BD postgres. Dans cette BD on a une table A, avec des champs ayants des contraintes d'intégrités referentiels vers une table B
 
cet BD est utiliés par un programme qui effectue des traitements un peu lourds, qui peuvent prendre plusieurs minutes. En début de traitement on fait un begin, en fin un commit, comme ca en cas de merde pendant le traitement la bd est pas pourrie.
 
Pb : pendant le traitement a un moment on fait un insert dans la table A. Ca fout un lock sur la table et si jamais on lance un deuxieme traitement en meme tps, celui ci va etre mis en attente, jusqu'au commit/rollback du premier traitement.  
 
Et ca nous gave; Y'a moyen d'eviter ca ?
 
accessoirement > quelle est la raison de ce lock ?

ah, et vous avez essayé en mettant les contraintes déférrées?
 
EDIT > euh non en immediate, plutôt, c'est l'inverse.

 
vous pouvez repeter la question ?  

les contraintes d'intégrité référentielle ont deux états possibles: IMMEDIATE et DEFERRED. En DEFERRED, les contraintes ne sont vérifiées qu'en fin de transaction, ce qui a pour effet de locker la table car on ne peut pas y toucher par ailleur tant que les contraintes n'ont pas été modifiées. Par contre en IMMEDIATE, les contraintes sont effectuées dirrectement. C'est un plus lent car le traitement ne se fait pas par lot, mais par contre, cela ne devrait plus locker la table le temps de la transaction.
 
la page qui donne la commande: http://www.postgresql.org/docs/7.4 [...] aints.html

merci alot ! vais essayer ca tout a l'heure

Je le savais... Pourquoi tu m'as pas demandé ?
 
 
 
 
 
 
 
 
 

 
(enfin, je sous traite, ces basses taches c'est pour les apprentis stagiaire, hein ?)

moué, bon, que ce soit :
 
begin;
set constraints all immediate;
insert into(...)
 
 
ou  
create table(.... REFERENCES truc INITIALLY IMMEDIATE)
 
ca bloque tjs

mmmh. Et c'est ton insert into qui est long dans ta transaction je suppose. Si c'est cela, y a pas de solution miracle, du moins pas avec les versions actuelles de PG. la table reste lockée durant tout le temps de l'insertion puisqu'elle doit vérifier les contraintes pendant l'insertion. Ce n'est qu'après l'insertion et le check des contraintes qu'elle est relachée hors de la transaction pour les autres accès en écriture. Et ça, tu ne sais pas y couper, autrement tu perdrais soit en perf globale, soit en intégrité.

 
heuh bin nan l'insert c'est vraiment un insert con et mechant, genre 2 chaines de caractere et un entier

ah, alors y a une couille ailleurs. Je vais tester chez moi. Vous avez quelle version de Pg?

 
on me souffle 7.2.3 dans mon oreillette (merci )

et ça te fait quoi de sentir mon souffle rauque à ton oreille?

 
arrete de manger du paté

je vois pas en quoi c'est con. Etant donné que A2 reste bloqué alors que A1 n'est bloqué à aucun moment, c'est bien A1 qui bloque A2.
Vu que tu ne fait de commit qu'à la fin de A1, cela sent à plein nez la ressource lockée par la transaction de A1.
 
Je ne sais pas comment PostGre SQL gère ses transactions, mais par exemple, SQL Server qui est un modèle de merdicité à ce niveau, fait un LOCK en écriture de toutes les tables qui participent à une transaction, sans ce soucier des informations d'un point de vue ligne (contraîrement à Oracle par exemple, qui réduit le scope du lock d'une transaction aux champs des lignes modifiés uniquement).
 
Si PostGre fait par exemple un LOCK sur la séquence ou l'objet qui sert de séquence afin de pouvoir rollbacker l'autoincrément au cas où la transaction merde, c'est aussi une source possible de ton problème, indémendament d'éventuel lock de table par une transaction.
 
Bref. Je ne lis pas plus loin, j'ai pas envie de lire une ligne de plus de ce topic ni d'avoir un soupçon d'envie de t'aider, vu la façon dont tu envoie chier une personne qui tente de répondre (à mon avis une immense exactitude dans la démarche).
 
Tu fais un peu trop la blonde à gros seins à mon goût. Le problème c'est que ça semble un peu trop naturel chez toi.

J'avais envoyé mon post trop vite, il en avait quoté l'intégralité...

 
je lis meme pas ton paté, t'arrives 15h apres la bataille, t'as rien compris et tu joues au chevalier blanc. Tes commentaires sur moi, tu te les fous ou je pense et tu vas jouer ailleurs. merci.

 
toi tu aurais mieux fait justement de lire tout le topic...
tu aurais compris l'humour sur la fausse blonde et sa binôme, le raté de la touche [tab] etc.
bref... des fois faut savoir fermer sa gueule, et tu viens de rater 1 belle occasion de le faire
 

J'ai craqué, j'ai lu trois posts plus loin, et bingo.
Bon, j'aurai au moins appris que PostGre utilise le même modèle de transactions merdiques que SQL Server. (comme quoi y'a pas que M$ qui sait pas développer )

c'est beau l'amour intra collegue

nan mais c'est bon quoi

Ah désolé de ma réaction initiale

Arf, en fin de compte j'ai vu les autres réactions, et nan, chuis pas désolé en fait, je confirme mes dire initiaux
 
Bref, le sujet est clot. Tu de démerdes pour sortir ton INSERT de la transaction histoire de faire un COMMIT immédiatement après et t'auras plus de problème.
Il faudra par contre dans le reste de ton traîtement prévoir un DELETE au cas où tu doit rollbacker ta transaction.
 
PS: t'es sûr d'être obligé d'utiliser une transaction ? Parceque mine de rien, si tu peux faire ton prog en autocommit, t'auras plus de problème de ressources lockées mais bon...

 
la même appli doit être lancée un nombre indéfini de fois sur le même serveur
une appli c'est un paquet de threads qui s'enchaînent
pour sécurité, les données ne sont validées qu'à la toute fin du traitement, on ne peut pas se permettre de les cummuler ou quoi que ce soit

J'ai pas parlé de les cumuler
 
J'ai dit que soit vous laissez tomber les transactions parceque ces threads ne sont pas critiques, soit vous forcez un commit après les lignes de la transaction qui font des locks emmerdant, quite à gérer la remise en l'état de la base de façon manuelle... Soit vous passez à un SGBD qui gère mieu les transactions (oubliez tout de suite SQL Server, qui le même problème, c'est pour cette raison que je sais exactement de quoi je parle, j'ai déjà été bloqué par ça).
 
Après, gizmo ou lorill, qui semble plus proche de la couche "DBA" des SGBD auront peut-être un mot-clé magique à vous fournir pour débloquer ça, mais j'en doute fortement (c'est tellement chiant comme limitation que ça serait déverrouillé par défaut si une méthode permettait de contourner)

 
pour le moment j'ai viré les contraintes d'intégrité référentielles, de toutes façons ce qu'on met dans les 2 tables qui posent problème, on va le chercher dans les autres tables jointes à coup de SELECT, donc la cohérence devrait être au rendez-vous...
ensuite, oui, on va creuser en espérant tomber sur le petit mot clé magique qui nous manque