Re: Frontend error logging style

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Frontend error logging style
Date: 2021-11-15 19:15:04
Message-ID: 632f02ed-12ac-b91f-0e99-9c1b086f8cd0@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-11-15 19:23:35 Re: refactoring basebackup.c
Previous Message Tom Lane 2021-11-15 19:14:36 Re: Test::More version