Re: Frontend error logging style
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2021-11-15T19:05:15Z
Lists: pgsql-hackers
On 09.11.21 23:20, Tom Lane wrote: > 1. The distinction between "error" and "fatal" levels seems squishy > to the point of uselessness. I think we should either get rid of it > entirely, or make an effort to use "fatal" exactly for the cases that > are going to give up and exit right away. Of the approximately 830 > pg_log_error calls in HEAD, I count at least 450 that are immediately > followed by exit(1), and so should be pg_log_fatal if this distinction > means anything at all. OTOH, if we decide it doesn't mean anything, > there are only about 90 pg_log_fatal calls to convert. I lean > slightly to the "get rid of the distinction" option, not only because > it'd be a much smaller patch but also because I don't care to expend > brain cells on the which-to-use question while reviewing future > patches. This logging system has been designed more generally, drawing some inspiration from Python and Java libraries, for example. It's up to the program using this to make sensible use of it. I think there are programs such as pg_receivewal where there is a meaningful distinction between errors flowing by and a fatal exit. But with something like pg_basebackup, there is no real difference, so that code sort of uses pg_log_error by default, since any error is implicitly fatal. I see the apparent inconsistency, but I don't think it's a real problem. Each program by itself has arguably sensible behavior.
Commits
-
logging: Also add the command prefix to detail and hint messages
- a8cca6026e99 15.0 landed
-
Remove not-very-useful early checks of __pg_log_level in logging.h.
- 2c9381840fe2 15.0 landed
-
Improve frontend error logging style.
- 9a374b77fb53 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 cited