|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: More consistency for some file-related error message|
|Views:||Raw Message | Whole Thread | Download mbox|
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> While looking at the source code for more consistency work with error
> messages, I have bumped into a couple of messages which could be
> simplified, as those include in the name of the file manipulated
> basically the same information as the context added.
> I have finished with the attached. Note that for most of the messages,
> I think that the context can be useful, like for example the stats
> temporary file which could be user-defined, so those are left out.
> There are also other cases, say the reorder buffer spill file, where we
> may not know the path worked on, so the messages are kept consistent as
> per HEAD.
> That's a bit less work to do for translators, particularly with
+1. Another thing I noticed is that we now have a fair amount of code
like this example in xlog.c:
errno = 0;
r = read(srcfd, buffer, nread);
if (r != nread)
if (r < 0)
errmsg("could not read file \"%s\": %m",
(errmsg("could not read file \"%s\": read %d of %zu",
path, r, (Size) nread)));
The short-read ereport has no errcode() call, meaning it will report
XX000, which seems like it's against project policy for foreseeable
errors. In this example ERRCODE_DATA_CORRUPTED seems better.
BTW, isn't the initial "errno = 0" dead code now?
regards, tom lane
|Next Message||Heikki Linnakangas||2018-07-18 14:58:16||Re: [HACKERS] WAL logging problem in 9.4.3?|
|Previous Message||Robert Haas||2018-07-18 14:56:31||Re: [HACKERS] logical decoding of two-phase transactions|