Re: Deadlock in libpq

On Thu, Mar 24, 2011 at 11:27 AM, Erik Hesselink <hesselink(at)gmail(dot)com> wrote:
> On Thu, Mar 24, 2011 at 17:18, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Thu, Mar 24, 2011 at 10:54 AM, Erik Hesselink <hesselink(at)gmail(dot)com> wrote:
>>> On Thu, Mar 24, 2011 at 16:43, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>>> 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.
>>>
>>> I just grepped the source, and PQInitSSL doesn't appear once. So I
>>> think it is never called at all. I'll try adding it to our application
>>> startup code, and see if that fixes the problem.
>>>
>>> This doesn't explain the broken connections without SSL though. I
>>> think if my threads were dying, I'd see a log message: there are top
>>> level exception handlers that log to email, file and the console. The
>>> connection code also has a handler that closes the connection in case
>>> of an exception.
>>
>> Also check PQinitOpenSSL.  For connections without SSL, all we know
>> for sure is that the tcp connection is unexpectedly getting dropped.
>> This could happen for all kinds of reasons -- like a miscreant router
>> deciding the connection is idle too long (this could in fact be the
>> issue aggravating the SSL lock issue, but that's worse and needs to be
>> caught and extirpated).
>
> PQinitOpenSSL also doesn't appear. I'll ask the HDBC maintainer if
> he's considered this issue.
>
> As far as connections getting dropped: yes, this sounds reasonable,
> but given that both the client and the server are running on the same
> machine, will connections (to 127.0.0.1) really be dropped once every
> 100.000 or so?

No, don't bother, I forgot the default behavior was to do both, which
is probably correct in your case. InitSSL just signals if you want
them to be done.

libpq refcounts connections and does SSL initialization when
connection count goes from 0->1 and destruction when it goes from
1->0. This operation is protected with mutex (you *are* using thread
safe libpq, right?).

merlin