Re: Frontend error logging style
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-15T19:15:04Z
Lists: pgsql-hackers
On 10.11.21 16:28, Robert Haas wrote: > 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. This is specifically designed not to do any flow control. In the backend, we have many instances, where log messages are issued with the wrong log level because the stronger log level would have flow control impact that is not appropriate at the call site. I don't think we want more of that, especially since the flow control requirements in the varied suite of frontend programs is quite diverse. Moreover, we also require control over the exit codes in some cases, which this kind of API wouldn't allow. Several programs wrap, say, pg_log_fatal() into a pg_fatal(), that does logging, cleanup, and exit, as the case may be. I think that's a good solution. If someone wanted to write a more widely reusable pg_fatal(), why not, but in my previous attempts, this was quite complicated and didn't turn out to be useful.
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