Re: Deadlock in libpq

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?

--
Erik Hesselink
http://silkapp.com