Tom Lane wrote:
> > It was mostly meant as a broad hint not to write "open() failed", which
> > can clearly be written more user-friendly without loss of information.
> > For less obvious cases we can use a mixed style. Say 'could not
> > synchronize file "%s" with disk (fsync failed)'. That tells people at
> > least that it's got something to do with their I/O subsystem.
>
> There are some places where we mention the syscall so that we can spell
> out the exact parameters that were passed, for possible debugging use.
> But this could probably be pushed to the "detail" message. So instead
> of
> IpcMemoryCreate: shmget(key=%d, size=%u, 0%o) failed: %m
> (plus a long hint)
> perhaps
> Primary: Could not create shared memory segment: %m
> Detail: Failed syscall was shmget(key=%d, size=%u, 0%o)
> Hint: as before
> Seem good?
I agree with this, but I believe the detail should really include
quite a lot of detail: the file and line number where the error
occurred, the error number returned by the syscall (if a syscall is
involved), parameters to the function that failed, and so forth. In
essence, I think enough detail should be included to make it possible
to determine exactly what went wrong and, hopefully, why it went
wrong. This stuff might not be terribly useful to the end user, but
it'll be of great use to a knowledgeable administrator (one of my pet
peeves is software that doesn't tell you why something failed, only
that it did).
--
Kevin Brown kevin@sysexperts.com