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.
