Re: "double free" segfault back in pyscopg2 2.5

>
>
> I'll make a release across the weekend. You should have a 2.5.1 by Monday.

Nice! Thanks.

Thank you again for fixing the same issue twice at 4 years distance. I'm
> very curious about your setup: if you could spend two words on it we may
> put together some stressing rig.
>

Glad to help. I think there is a combination of factors in our usage
pattern of psycopg that increases the likelihood these kinds of issues
surfacing:

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.

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.

Please let me know if further information is needed.

Thanks,
Gangadharan

On Thu, Jun 20, 2013 at 9:24 PM, Daniele Varrazzo <
daniele(dot)varrazzo(at)gmail(dot)com> wrote:

> On Thu, 2013-06-20 at 21:17 +0530, Gangadharan S.A. wrote:
> > Thanks! Yes, this change should fix the issue - and it did in my testing.
> >
> > Do we know of a rough esitmate on when this will be released as a
> version?
>
> I'll make a release across the weekend. You should have a 2.5.1 by
> Monday.
>
> Thank you again for fixing the same issue twice at 4 years distance. I'm
> very curious about your setup: if you could spend two words on it we may
> put together some stressing rig.
>
> Cheers,
>
> --
> Daniele
>
>