Re: Broken pipes

I had experienced these errors in PHP with large selects (from a web
perspective--maybe a few thousand rows). It may have to do with the memory
limit imposed on PHP (se php.ini file). The symptom on the client end is
that the page seem to try to load until a timeout would be expected but then
it just quits.

You questions you want to ask yourself: 1) Are there any selects returning
rows larger than can be practically handled in a web browser? 2) have you
tried increasing the memory limit of PHP?

In my case, the solution was correcting my SQL statement where a syntactical
ambiguity was causing a cross join to occur.

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"

> From: "mike sears" <matrix(at)quadrent(dot)net>
> Date: Sat, 27 Oct 2001 01:01:07 -0400
> To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc: <pgsql-general(at)postgresql(dot)org>
> Subject: Re: [GENERAL] Broken pipes
>
> I dunno if this makes any differnec or not, but we use php to interface w/
> postgress. Could this also have anything to do with this problem?
>
> as well would this surpression be in the current snapshots?
>
> Mike
>
> ----- Original Message -----
> From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: "mike sears" <matrix(at)quadrent(dot)net>
> Cc: <pgsql-general(at)postgresql(dot)org>
> Sent: 26 October, 2001 7:30 PM
> Subject: Re: Broken pipes
>
>
>> "mike sears" <matrix(at)quadrent(dot)net> writes:
>>> pq_recvbuf: unexpected EOF on client connection
>>
>> This indicates that you have clients that are disconnecting
>> ungracefully, but it doesn't tell us much about why.
>>
>> One recently-understood possibility is that if you are using psql
>> with password authentication, then psql doesn't prompt you for a
>> password until it's tried and failed to connect without. That
>> failure provokes one of these messages. (For 7.2, we've hacked the
>> postmaster to suppress the log message in that case.)
>>
>> Otherwise you have misbehaving client-side software. I think that
>> the ODBC driver is known not to disconnect gracefully, but I don't
>> know of any other problems that would cause this, short of client
>> crashes.
>>
>> regards, tom lane
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 6: Have you searched our list archives?
>>
>> http://archives.postgresql.org
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>