From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | "Gangadharan S(dot)A(dot)" <gangadharan(at)gmail(dot)com> |
Cc: | "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org> |
Subject: | Re: "double free" segfault back in pyscopg2 2.5 |
Date: | 2013-06-20 17:48:05 |
Message-ID: | 1371750485.3159.23.camel@risotto.smithersbet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Thu, 2013-06-20 at 22:18 +0530, Gangadharan S.A. wrote:
> 1. We subclass the connection class and pass it in as
> connection_factory argument to psycopg2.connect() . Subclassing is
> necessary to make the garbage collector worry about this object having
> cyclic references and try tp_clear on it. This is how we end up in a
> place where the reference counting based destruction of the object on
> one thread coincides with the garbage collector trying to free the
> same object from another thread. The subclass definition of the
> connection class can simply be a "pass" statement and need not
> implement any actual functionality.
Do you mean a plain Python subclass or a C type subclass? A failed
attempt at creating connection/cursor C subclasses some times ago led me
to review the objects GC interaction (and re-introduce the bug).
> 2. We have 100s of threads connecting to 100s of databases rationed
> out by a connection pool manager library. Connections are closed and
> opened frequently.
I guessed that was the minimum :)
> Please let me know if further information is needed.
How long have you been running 2.5 in production? Any other issue to
report that may be fixed for 2.5.1?
--
Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Gangadharan S.A. | 2013-06-20 17:59:53 | Re: "double free" segfault back in pyscopg2 2.5 |
Previous Message | Gangadharan S.A. | 2013-06-20 16:48:43 | Re: "double free" segfault back in pyscopg2 2.5 |