Bonjour,
j'ai fait le tour de quelques trucs, voici ce que j'ai analysé le mesage d'erreur est dû au fait que psycog, quand un pb survient, tente de rollback avant de fermer la connexion, mais comme c'est déjà fermé le rollback produit le message "connection already closed". http://www.postgresql.org/message-id/CA+mi_8a3QoF5rLL0QFV2foU=KO+Cc4-jx3L=czws8kmup+o...@mail.gmail.com En relisant ce que vous mettez "en retirant atomic() ca marche avec des erreurs" ; je suis perplexe ; pourquoi le framework, avec le get_or_create() ferait le create s'il parvient à faire le get ? c'est pas là le problème ? On dirait qu'il ne fait JAMAIS le get et plante constamment sur le create quand le record est déjà dans la table. Si vous solutionnez ce comportement, peut-etre que ca contenterait mieux .atomic() ? My 2 coins de noob assis dans le fond ;) Cordialement Le 02.12.2014 00:35, Olivier Cortes a écrit : > Re, > > et merci pour la réponse. > > Le lundi 01 décembre 2014 à 21:20 +0100, FoxMaSk a écrit : > >> Hello, j'aurai bien fait une vanne sur "mais quelle hérésie une biere au >> pays du rouge" mais bof > > ouais, je suis pas sectaire sur la boisson ;-) > >> Par contre que disent les logs du SGBDR ? Quelle est-elle ? Oracle ? >> Postgresql ? > > PostgreSQL 9.3 sur http://1flow.io/ [1] et ma machine de dév, et 9.1 sur > d'autres instances. Le problème est commun aux deux versions, et se > produit avec DEBUG=True et DEBUG=False. > >> Là, genre, paradoxalement, j'aurai plutôt conservé des connexions >> persistantes (si elle ne le sont pas) et je me demande s'il n'y a justement >> pas assez de cursors ouverts pour traiter toutes les demandes, ce qui du >> coup, lorsqu'arrive le moment d'en traiter une, qui n'a plus "sa place" ; >> lâche. > > Les logs de PG n'indiquent rien de particulier au moment des problème, > ce qui est plutôt rassurant (ou pas) : lorsque les crash se produisent > avec transaction.atomic(), en fait il n'y a aucun problème particulier ; > j'en veux pour preuve que si je l'enlève, tout va bien (sauf un cas > d'erreur légitime sur X milliers de requêtes). > > Les logs de PG ne sont pas vides, loin s'en faut, mais ils ne > contiennent que des : > > 2014-11-30 17:20:23 UTC ERROR: duplicate key value violates unique > constraint "core_article_url_key" > 2014-11-30 17:20:23 UTC DETAIL: Key > (url)=(http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_le_monde_metal/ > [2]) already exists. > 2014-11-30 17:20:23 UTC STATEMENT: INSERT INTO > "core_article" ("baseitem_ptr_id", "url", "comments_feed_url", > "url_absolute", "url_error", "is_orphaned", "ima > ge_url", "excerpt", "content", "content_type", "content_error", > "word_count") VALUES (16918397, > 'http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_ [3] > le_monde_metal/', NULL, false, NULL, false, NULL, NULL, NULL, NULL, > NULL, NULL) > > Qui sont les erreurs « normales » qui se produisent lors des > get_or_create() ou des update_or_create() (ah non mince lui c'est que > dans Django 1.7 ; en 1.6 je ne l'ai pas. Bien dommage d'ailleurs. Bref.) > >> Mais avant de partir trop loin en conjecture, les logs seraient pratique. > > Ben voilà. Je peux te mettre un log en accès FTP qq part, mais à > première vue c'est peine perdue. Sans compter qu'une journée de log, > c'est 200Mo minimum, à tendance 1.5Go... Si vraiment vous êtes demandeurs, > je ferai un extrait avant / après activation d'atomic(). > > Je viens de lire la doc des connexions persistantes, ça a l'air > alléchant. Pour l'instant, je n'ai rien changé (j'essaierai plutôt > demain, après une nuit de sommeil...). > > J'avais monté le nombre de connexions parallèles à 256 dans > postgresql.conf pensant que ça pouvait éventuellement être lié (sans > grande motiv' parce que je vois pas pourquoi, en fait), mais ça n'a rien > changé. Faut dire qu'avec la configuration par défaut (100 connexions je > crois), ça passait très bien, et avec le bug que je rencontre sur > atomic(), quelle que soit la valeur, ça pète. > > a+ et merci aux courageux qui lisent mes mails jusqu'au bout. Bonne > nuit, > > -- > Olivier > http://oliviercortes.com/ [4] > http://1flow.io/ [1] > > _______________________________________________ > django mailing list > [email protected] > http://lists.afpy.org/mailman/listinfo/django [5] Links: ------ [1] http://1flow.io/ [2] http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_le_monde_metal/ [3] http://www.reddit.com/r/Music/comments/2nuhqs/megadeth_a_tout_ [4] http://oliviercortes.com/ [5] http://lists.afpy.org/mailman/listinfo/django
_______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
