On 2018-Jun-11, Robbie Harwood wrote: > It might be less confusing to just set errno if it's not set already > (e.g., to EIO, or something). Up to you though - this is a bit of a > niche case.
I think that would be very confusing, if we receive a report that really is a short read but looks like EIO. I'm for keeping the code as proposed. As for the messages, I propose to make them more regular, i.e. always use the wording "could not read from file "%s": read %d, expected %zu", avoiding variations such as not enough data in file \"%s\": %d read, %d expected" could not read compressed file \"%s\": read %d out of %zu could not read any data from log segment %s, offset %u, length %lu and others that appear in other places. (In the last case, I even go as far as proposing "read %d, expected %zu" where the the first %d is constant zero. Extra points if the sprintf format specifiers are always the same (say %zu) instead of, say, %d in odd places. I would go as far as suggesting to remove qualifiers that indicate what the file is for (such as "relation mapping file"); relying on the path as indicator of what's going wrong should be sufficient, since it's an error that affects internals anyway, not anything that users can do much about. Keep variations to a minimum, to ease translator's work; sometimes it's hard enough to come up with good translations for things like "relation mapping file" in the first place, and they don't help the end user. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services