Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> 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 banderas No reconocemos fronteras" (Jorge González) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
