Re: Fix some error handling for read() and errno

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robbie Harwood <rharwood(at)redhat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, magnus(at)hagander(dot)net, hlinnaka(at)iki(dot)fi
Subject: Re: Fix some error handling for read() and errno
Date: 2018-06-11 22:17:15
Message-ID: 20180611221715.vs5s3oow3vyxj4pq@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-06-11 18:11:05 -0400, Alvaro Herrera wrote:
> 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.

If we go there, why not wrap the read/write/etc calls into a wrapper,
including the error handling?

I'm not quite convinced that "relation mapping file" doesn't provide any
information. It's likley to be easier to search for than a specific
filename, particularly if there's oids or such in the name...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-11 22:24:04 Re: why partition pruning doesn't work?
Previous Message Alvaro Herrera 2018-06-11 22:11:05 Re: Fix some error handling for read() and errno