Re: segmentation faults with psycopg2 and multiprocessing
От | Daniele Varrazzo |
---|---|
Тема | Re: segmentation faults with psycopg2 and multiprocessing |
Дата | |
Msg-id | CA+mi_8b7O7tTW+gQKau1hZy3iSqbgSD7RDPk4xJ_=MzAhaZecg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: segmentation faults with psycopg2 and multiprocessing (Ryan Kelly <rpkelly22@gmail.com>) |
Ответы |
Re: segmentation faults with psycopg2 and multiprocessing
|
Список | psycopg |
On Fri, Sep 28, 2012 at 10:03 PM, Ryan Kelly <rpkelly22@gmail.com> wrote: >> Can you produce a traceback? > Or maybe this new one is better? They are both fine, I can see the error is during a rollback, in the Python API call that queries whether there is a Python exception set. Just... it doesn't make sense: the only way that function may bomb, I think, is when we call it without holding the GIL, and it is actually acquired the line above. Reading again you original post: you connect from the children and the parent crashes? I think I'm reading it wrong... Also, what do you mean that "you have added a connection": the app was already using psycopg and you are now connecting to a new database too? Ritual questions: what psycopg, postgres and python versions are? Are you using any "magic": greenlet, signals, threads, apart from processing? The rollback issued looks called from Python, not internally. Does your program call conn.rollback() in some strange situation, such as in an object __del__ or at application cleanup? A last useful piece of info: could you compile psycopg with debug info on (see setup.cfg) and run it with the info (set the env var PSYCOPG_DEBUG before running the program)? We may find something in the logs. Thank you. -- Daniele
В списке psycopg по дате отправления: