On Tue, Nov 26, 2024 at 11:36 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think the idea was that this mechanism is equivalent to an EMFILE > limit. But if you feel a need to make a distinction, this seems fine:
I think we should never, ever confuse an error return from a system call with any other kind of problem that can happen. Not even write() returns 0 => ENOSPC. AFAIK, the rationale for conflating failure cases like this is that either both failures are unlikely or, at least, the case where errno wasn't actually set is unlikely. But the problem is that when something weird happens, that's exactly when you need a clear and unambiguous error report. I've had multiple extremely painful support experiences that were made painful precisely because I couldn't determine exactly what really happened. Did a system call really return an unlikely error code? Or was it the not-a-real-error-code-but-we-faked-one case which is also not supposed to happen? I find this kind of thing maddening every time it happens, and it happens to me more often than you might think, because it often happens that other people are able to answer the normal questions and they send me the weird ones. Let's say twice a year I spend a couple of days sweating blood trying to determine the root cause of some bizarre malfunction because the person who wrote the code couldn't be bothered to take 2 minutes to make the errors distinguishable. -- Robert Haas EDB: http://www.enterprisedb.com
