On Tue, Nov 9, 2021 at 5:20 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > 1. The distinction between "error" and "fatal" levels seems squishy > to the point of uselessness. > > 2. What is the preferred style for adding extra lines to log messages?
I agree with this list of problems. I think that the end game here is getting to be able to use ereport() and friends in the frontend, which would require confronting both of these issues at a deep level. We don't necessarily have to do that now, though, but I think it's an argument against just nuking "fatal" from orbit. What I think we ought to be driving towards is having pg_log_fatal() forcibly exit, and pg_log_error() do the same unless the error is somehow caught. That might require more changes than you or whoever wants to do right now, so perhaps what we ought to do is just enforce the policy you suggested before: if we're going to exit immediately afterward, it's fatal; if not, it's an error. I have been wondering for some time about trying to make the frontend and backend facilities symmetric and using case to distinguish. That is, if you see: ERROR: this stinks DETAIL: It smells very bad. CONTEXT: garbage dump ...well then that's a backend message. And if you see: error: this stinks detail: It smells very bad. context: garbage dump ...well then that's a frontend message. I don't completely love that way of making a distinction, but I think we need something, and that's pretty nearly the present practice at least for the primary message. We don't really have a solid convention for detail/context/hint on the FE side; this is one idea. -- Robert Haas EDB: http://www.enterprisedb.com
