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