Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Tom Lane wrote:
> >> That analysis is full of holes --- FileRead and FileWrite for starters.
>
> > I already did. The case where they retry do not call _dosmaperr.
>
> What's retry got to do with it? What's displeasing me is the idea of
> LOG messages showing up during perfectly normal operation.
Oh, I see your point. It's that those routines will sometimes be
called, they return an error, and this is *ignored* by the caller. In
the case of FileRead, the only such caller is ExecHashJoinGetSavedTuple.
In the case of FileWrite, the thing is quite a bit more difficult to
follow, but it goes through BufFileWrite and BufFileFlush.
So yeah, it seems there is valid code trying to call FileRead and
FileWrite, have it error out, and silently ignore the error. I'm not
going to argue this late in the cycle that all that code be changed, so
I think a reasonable compromise is to turn the ereport() in _dosmaperr
to DEBUG1 instead. That way it won't clutter any log by default, and in
the cases where we're actually interested in tracking the problematic
situation, we don't need to get huge amounts of log traffic coming from
other parts of the system.
All the cases where BufFileFlush is called and it ignores an error are
bugs. I think it's quite safe to modify BufFileFlush to ereport(ERROR)
if it cannot do what it was asked.
And all the callers of BufFileWrite immediately ereport() if it cannot
write the specified amount of bytes.
So there is exactly one case where these routines would be unnecessarily
noisy, and that is ExecHashJoinGetSavedTuple.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"No necesitamos banderasNo reconocemos fronteras" (Jorge González)