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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
