Re: Strange hanging bug in a simple milter

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

In response to

Responses

Browse pgsql-hackers by date

  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