From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> TBH, I think you are worried about the wrong thing here. You could drop
> both of those errdetail calls altogether and be little worse off. In the
> places where we have errdetail calls like "failed system call was xxx",
> the main point is to show the exact parameters that were given to the system
> call, and neither of these do that. These errdetail messages would only
> be useful if the identical ereport errmsg might be issued for failures from
> different underlying Windows calls --- but I doubt that's what you're
> intending here.
Yes, that's what I'm intending to do. To enable the user right "Lock pages in memory" on Windows, a few Win32
functionsneed to be called in turn.
> My problem with these messages is I am not sure what "memory user right"
> means. Probably that just needs a bit of editing. But I'd go for something
> like "could not do xxx: error code %lu", and not bother mentioning the system
> call name, unless failing to do so has some impact on whether we could
> understand what happened from a field report of this error message.
For the user, each step of enabling the user right is irrelevant. It just matters to him that that the server could
notenable the user right. OTOH, the failed Win32 function may help us to talk with Microsoft to troubleshoot the
problem. So I used the same messages in those ereport() calls except for the function name to eliminate the translation
work.
> (See the "Function Names" item in our message style guidelines for more
> about this issue. Maybe we need to expand that item some more.)
The style guide does not necessarily require the function parameter values.
https://www.postgresql.org/docs/devel/static/error-style-guide.html
[Quote]
If it really seems necessary, mention the system call in the detail message. (In some cases, providing the actual
valuespassed to the system call might be appropriate information for the detail message.)
postmaster.c doesn't display parameter values, too.
elog(LOG, "CreateProcess call failed: %m (error code %lu)", GetLastError());
Regards
Takayuki Tsunakawa