Thread: Multiple pq_flush: send() failed: Broken pipe

Hi all,
    I have my logfile flooded with the message:

pq_flush: send() failed: Broken pipe

I went through the archives and I found plenty of (older) cases where this was usually accompanied by a 'FATAL:'
messageand lead to a crash. In my case there is only this by itself (*many* times) and it doesn't lead to a crash. Any
ideawhat could be causing it? I'm on Pg 7.1.1 on a linux 2.4.4 

TIA,
thalis

"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
>     I have my logfile flooded with the message:
> pq_flush: send() failed: Broken pipe
> I went through the archives and I found plenty of (older) cases where
> this was usually accompanied by a 'FATAL:' message and lead to a
> crash. In my case there is only this by itself (*many* times) and it
> doesn't lead to a crash. Any idea what could be causing it?

Perhaps some backend churning away on a SELECT that produces gigabytes
of output?  (Not hard to do with a careless unqualified join ...)
The client might have long since given up and disconnected, but right
now the backend won't notice until it finishes the query.

Send a SIGINT to the errant backend to get it to cancel the query.

            regards, tom lane

The truth of the matter is that I have queries that take too long to execute and I sometimes interrupt them with ^C. I
assumethe backend dies when the frontend receives this, correct? 
So if that's the case, there is no harm other than that the logfile gets really fat (e.g. potential server crash at
somepoint?) 

t.


On Wed, 13 Jun 2001, Tom Lane wrote:

> "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> >     I have my logfile flooded with the message:
> > pq_flush: send() failed: Broken pipe
> > I went through the archives and I found plenty of (older) cases where
> > this was usually accompanied by a 'FATAL:' message and lead to a
> > crash. In my case there is only this by itself (*many* times) and it
> > doesn't lead to a crash. Any idea what could be causing it?
>
> Perhaps some backend churning away on a SELECT that produces gigabytes
> of output?  (Not hard to do with a careless unqualified join ...)
> The client might have long since given up and disconnected, but right
> now the backend won't notice until it finishes the query.
>
> Send a SIGINT to the errant backend to get it to cancel the query.
>
>             regards, tom lane
>

"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> The truth of the matter is that I have queries that take too long to
> execute and I sometimes interrupt them with ^C. I assume the backend
> dies when the frontend receives this, correct?

If you're using psql, it catches ^C and sends a QueryCancel request to
the backend.  If you're using something else that just aborts the
client, then the backend will finish out the current query before it
notices that the client connection is lost (whereupon it rolls back the
current transaction and quits).  So ^C'ing a simple client isn't the
ideal way to cancel a hugely long query at the moment.

> So if that's the case,
> there is no harm other than that the logfile gets really fat

AFAIK, no problem other than waste of cycles.

We were discussing changing this just a few days ago on pghackers,
however.  7.2 will probably cancel the current query as soon as it
gets the first send() failure.

            regards, tom lane

> The client might have long since given up and disconnected, but right
> now the backend won't notice until it finishes the query.

That has the sound of something that might change in the near future? I'd
love to automatically have runaway queries killed when the client drops the
connection...

Greg

"Gregory Wood" <gregw@com-stock.com> writes:
>> The client might have long since given up and disconnected, but right
>> now the backend won't notice until it finishes the query.

> That has the sound of something that might change in the near future? I'd
> love to automatically have runaway queries killed when the client drops the
> connection...

See followup: what was being discussed a couple days ago was cancelling
the query as soon as send() failure is detected.  That's not a complete
solution, since there's still a problem with the sort of query that
computes for hours before it tries to emit any output.  But it'd be a
big improvement.

Note that since 7.0 or so you can kill a runaway query harmlessly by
sending the backend a SIGINT, even if the client has disconnected.

            regards, tom lane