X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id A1F0830EE99 for ; Fri, 27 Jun 2003 03:58:06 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 80207-03 for ; Fri, 27 Jun 2003 00:57:56 -0300 (ADT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 8FBD631017A for ; Fri, 27 Jun 2003 00:57:55 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h5R3vsQQ024603; Thu, 26 Jun 2003 23:57:54 -0400 (EDT) To: Forest Wilkinson Cc: pgsql-interfaces@postgresql.org, dfs@roaringpenguin.com Subject: Re: Weird behaviour on Solaris: recv() returns ENOENT In-reply-to: References: Comments: In-reply-to Forest Wilkinson message dated "Thu, 26 Jun 2003 18:04:00 -0700" Date: Thu, 26 Jun 2003 23:57:54 -0400 Message-ID: <24602.1056686274@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200306/89 X-Sequence-Number: 4300 Forest Wilkinson writes: > I'm having a similar problem, but instead of ENOENT I'm getting what > appears to be ECONNREFUSED. (PQresultStatus() says "Connection > refused".) This is on a Solaris 9 box, with Postgres 7.3.2 and 7.3.3, > using libpq in a multithreaded program. At the same time, postgres ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libpq is not as thread-safe as the documentation alleges :-(. The library itself doesn't do anything un-thread-safe, but it calls several libc routines that are not thread-safe on many platforms. We are trying to fix this for 7.4. I am not certain that this is the explanation for your problems though. IIRC, most of the known gotchas occur during connection startup, and would not explain a failure in a running connection. Are you both honoring the restriction that two threads can't concurrently do operations on the same PGconn object? We provide no locking that would make that safe, but consider it the application's responsibility to do so if needed. I strongly suspect that David's problem is of this ilk, less sure about Forest's. regards, tom lane