Re: segmentation faults with psycopg2 and multiprocessing

On Fri, Sep 28, 2012 at 10:27:03PM +0100, Daniele Varrazzo wrote:
> On Fri, Sep 28, 2012 at 10:03 PM, Ryan Kelly <rpkelly22(at)gmail(dot)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?
I have connections open in the parent process. I fork via
multiprocessing. I open new connections for use in the children. When
control returns to the parent, I attempt to execute a query, and at that
point I get a segmentation fault.

> Ritual questions: what psycopg, postgres and python versions are?
psycopg2: 2.4.2
postgres: 9.1.2
python: 2.7.1+

> Are you using any "magic": greenlet, signals, threads, apart from processing?
Nope. Not that I know of anyway.

> 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?
Presumably sqlalchemy is calling ROLLBACK on error.

> 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.
Will do.

>
> Thank you.
>
> -- Daniele

-Ryan Kelly