I wrote:
> After still further thought, it seems like "if (bytesread == 0)"
> is the right way to proceed. That protects us against incorrectly
> setting reached_eof if the pipe is being run in unbuffered or
> line-buffered mode. (Which copy.c doesn't do, at the moment,
> but I'd just as soon this code didn't need to assume that.
> Also, I'm not 100% convinced that Windows or other platforms
> might not act that way.) In the case where we terminate early
> because we saw an in-band EOF marker, we would also not set reached_eof,
> and again that seems like a good outcome: if we see SIGPIPE it
> must mean that the program kept sending data after the EOF marker,
> and that seems like a good thing to complain about. (It's only
> guaranteed to fail if the program sends more than the current pipe
> buffer-ful, but I don't feel a need to add extra code to check for
> nonempty buffer contents as we exit.)
Oh, wait, that last bit is backwards: if we see an in-band EOF mark,
and as a consequence exit without having set reached_eof, then the
exit code will think that SIGPIPE is ignorable. So transmitting
more data after an EOF mark will not be complained of, whether
it's within the same bufferload or not.
Still, I can't get very excited about that. Potentially we could
improve it by having the places that recognize EOF marks set
reached_eof, but I'm unconvinced that it's worth the trouble.
I'm thinking that it's better to err in the direction of reporting
SIGPIPE less often not more often, considering that up to now
we've never reported it at all and there've been so few complaints.
regards, tom lane