Re: Deadlock in libpq - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Deadlock in libpq
Date
Msg-id AANLkTinMv14a5PfD_LWw_nn7-d9xMSOBJ0GtfxH_S3D_@mail.gmail.com
Whole thread Raw
In response to Re: Deadlock in libpq  (Erik Hesselink <hesselink@gmail.com>)
Responses Re: Deadlock in libpq  (Erik Hesselink <hesselink@gmail.com>)
List pgsql-general
On Thu, Mar 24, 2011 at 10:54 AM, Erik Hesselink <hesselink@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 16:43, Merlin Moncure <mmoncure@gmail.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).

merlin

pgsql-general by date:

Previous
From: salah jubeh
Date:
Subject: which view is used another views
Next
From: Erik Hesselink
Date:
Subject: Re: Deadlock in libpq