From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Vesa-Matti J Kari <vmkari(at)cc(dot)helsinki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Strange hanging bug in a simple milter |
Date: | 2013-09-13 19:26:07 |
Message-ID: | 523366CF.6030801@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13.09.2013 22:03, Stephen Frost wrote:
> * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
>> It seems slightly cleaner to just move the pqsecure_destroy(); to the
>> end of that function, based on a boolean. But if you think otherwise, I
>> won't protest...
>
> Hmm, agreed; I had originally been concerned that the SIGPIPE madness
> needed to be around the pqsecure_destroy() call, but I can't see why
> that would be.
>
> I've run through a few times w/ the attached and haven't seen the
> deadlock. Will continue testing, of course.
>
> Heikki, any thoughts regarding this change? Any concerns about
> back-patching it?
Umm, with that patch, pqsecure_destroy() is never called. The "if
(conn->ssl)" test that's now at the end of the close_SSL function is
never true, because conn->ssl is set to NULL earlier.
I'm afraid the "move_locks.diff" patch you posted earlier is also
broken; close_SSL() is called in error scenarios from
pqsecure_open_client(), while already holding the mutex. So it will
deadlock with itself if the connection cannot be established.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-09-13 19:32:26 | Re: Strange hanging bug in a simple milter |
Previous Message | Andres Freund | 2013-09-13 19:23:49 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |