On Thu, Mar 24, 2011 at 17:18, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Thu, Mar 24, 2011 at 10:54 AM, Erik Hesselink <hesselink@xxxxxxxxx> wrote: >> On Thu, Mar 24, 2011 at 16:43, Merlin Moncure <mmoncure@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
