Thread: Re: Weird behaviour on Solaris: recv() returns ENOENT

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
writes "pq_recvbuf: unexpected EOF on client connection" to syslog
several times.

It seems to occur at random times, just after a perfectly legal query
was issued.  I'm looking futher into the program flow in hopes of
discovering a bug, but the problem doesn't show up in the same code
when both the program and postgres are running on linux.

What could be going on here?  David, did you ever resolve your
problem?


"David F. Skoll" (dfs@roaringpenguin.com) wrote:

>Hi,
>
>I'm having a customer running PostgreSQL 7.2.3 on Solaris 9 with
>PHP 4.3.0, and he's getting this error:
>
> could not receive data from server: No such file or directory
>
>grepping through the libpq source, it appears that the only way this
>message could happen is if recv() returns -1 with errno set to ENOENT.
>This is not one of the documented recv() error codes!
>
>My questions:
>
>1) Has anyone else ever seen this?
>2) Is libpq thread-safe?  Do you need to compile with special flags to
>   make it thread-safe?  My first guess is that he's using a multithreaded
>   version of PHP (with iPlanet Web server) and errno is not behaving properly.
>
>Regards,
>
>David.

Forest Wilkinson <lyris-pg@tibit.com> 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

On Thu, 26 Jun 2003, Forest Wilkinson wrote:

> I'm having a similar problem, but instead of ENOENT I'm getting what
> appears to be ECONNREFUSED.

> What could be going on here?  David, did you ever resolve your
> problem?

I didn't exactly resolve the problem, but we fixed it to my
satisfaction.  The problem appeared when the customer was using PHP
with PostgreSQL in the multi-threaded iPlanet server.  It went away
when he switched to the single-threaded Apache.

Since we only "officially" support our product under Apache, I considered
the problem solved.

--
David.