From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Vesa-Matti J Kari <vmkari(at)cc(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Strange hanging bug in a simple milter |
Date: | 2013-09-09 17:26:10 |
Message-ID: | 20130909172610.GR2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro,
* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Heikki Linnakangas wrote:
> > I'll dig into that, but right now it seems like an OpenSSL or
> > libcrypto bug to me. Or something in the way we use them, although I
> > can't see anything obviously wrong in the libpq code at a quick
> > glance.
>
> Can you please try with ssl_renegotiation_limit=0?
>
> [ looks ] Uh, actually you don't even send data in those connections in
> your test program, do you? Maybe there's a problem with the mutex stuff
> committed recently by Stephen.
I was wondering about that also, but it was apparently an issue even
before that change (it was reported against 9.1.9). Also, Heikki's
analysis appears to show cases where two threads end up waiting on the
same entry in the lockarray, which I don't think my changes would have
impacted at all.
In any case, I hope to find time this afternoon/evening to try this
against libpq from before and after, just to be sure and rule out that
patch. Assuming that pans out, I tend to agree w/ Heikki that we should
test this outside of libpq entirely and see if we can reproduce it.
Even if we're able to do that, we may need to consider ways to fix it
ourselves (perhaps be holding heavier locks or something), as we have no
idea how long it'll take an OpenSSL fix to happen..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-09-09 17:31:22 | Re: Custom Plan node |
Previous Message | Tom Lane | 2013-09-09 17:20:42 | Re: Custom Plan node |