Re: Strange hanging bug in a simple milter

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

In response to

Browse pgsql-hackers by date

  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