From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
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:41:09 |
Message-ID: | 20130913194109.GC2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> Actually, I think there's a pre-existing bug there in git master. If
> the SSL_set_app_data or SSL_set_fd call in pqsecure_open_client
> fails for some reason, it will call close_SSL() with conn->ssl
> already set, and the mutex held. close_SSL() will call
> pqsecure_destroy()->destroy_SSL()->destory_ssl_system(), which will
> try to acquire the mutex again.
Yeah, good point, and that one looks like my fault. Moving it after the
unlock should address that tho, no? Looking through the other
close_SSL() calls, I don't see any other situations where it might be
called with the lock held.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-09-13 19:55:16 | Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Previous Message | Josh Berkus | 2013-09-13 19:36:58 | Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |