Re: Deadlock in libpq

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Erik Hesselink <hesselink(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Deadlock in libpq
Date: 2011-03-24 16:18:21
Message-ID: AANLkTinMv14a5PfD_LWw_nn7-d9xMSOBJ0GtfxH_S3D_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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).

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Erik Hesselink 2011-03-24 16:27:52 Re: Deadlock in libpq
Previous Message salah jubeh 2011-03-24 16:06:17 which view is used another views