Message-ID: <632f02ed-12ac-b91f-0e99-9c1b086f8cd0@enterprisedb.com>
Date: Mon, 15 Nov 2021 20:15:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Frontend error logging style
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <1363732.1636496441@sss.pgh.pa.us>
 <CA+TgmoZjmJF0bTfd_q7yXWCR9cp0n6XgBHM7XPPy7R9jSWrJCQ@mail.gmail.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <CA+TgmoZjmJF0bTfd_q7yXWCR9cp0n6XgBHM7XPPy7R9jSWrJCQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/632f02ed-12ac-b91f-0e99-9c1b086f8cd0%40enterprisedb.com>
Precedence: bulk

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.