Re: Deadlock in libpq

On Thu, Mar 24, 2011 at 10:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> *something* must be initializing ssl, or you can't make secure
>> connections from libpq.  you need to find out which pq ssl init
>> function is begin called, when it is being called, and with what
>> arguments. One of the main things PQInitSSL does is set up a lock
>> vector which it passes to the crypto library.  The fact you are having
>> blocking issues around those locks is suggesting SSL was not set up
>> properly, something happened after being set up so that the locks are
>> no longer good, you have application thread issue (although that
>> sounds unlikely), or (least likely worst case) there is a bug in
>> crypto.
>
> Given that Erik still sees trouble when not using SSL, my money would
> be on the idea that somewhere he's got two threads trying to use the
> same connection object concurrently.  The SSL confusion is just one
> symptom of that.

maybe -- but aside from the fact the OP is disclaiming that case, I'm
not convinced you would see strictly 'broken pipe' error resulting
from connection synchronization problems (surely, you'd see other
problems eventually). Maybe one of his threads is dying and
aggravating some other client side problem. Also, he's getting
blocked in connection establishment.

He needs to rule out the most obvious problem first -- PQInitSSL being
called improperly or at the wrong time. OP: It's a library wide
setting and must be called before the first connection is established
and only once. Perhaps the HDBC driver has some bad logic there.

merlin