Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNDpg-0002LK-H4 for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Feb 2022 13:06:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nNDpf-00074i-B5 for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Feb 2022 13:06:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNDpe-0006zt-6o for pgsql-hackers@lists.postgresql.org; Thu, 24 Feb 2022 13:06:55 +0000 Received: from [66.111.4.28] (helo=out4-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNDpa-0008EW-Oj for pgsql-hackers@lists.postgresql.org; Thu, 24 Feb 2022 13:06:53 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 629B35C0CE4; Thu, 24 Feb 2022 08:06:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 24 Feb 2022 08:06:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=piLaHOZ6QsWhcm3ZBXoEd37nzQPFXEm2x6/UVY9oJ z4=; b=BTZq5TM3nvO3NbmjCcvd6zMaMPtermCpnNimyI64Lrbh8F15I6tjqcASh MyuAltFdpLszyZDk84XezdHFkl9rCA053U3cyWdh+NpB+4k9rwVWfeYXSQccF8M2 nQKBGuG2vHcwwv6cOLrldrX3cUpAJ59sdmOnAbTQfl8jdWdtjOA/K14W9jphiEGB dKQr6HjMfmjs99XeFTXBE5YksaojmMpUzYo5JdKHq0UOiw8v7a5GNjwT4SbJkTLY +b5Z7dHOgg0/IQPMa4FK47ml9O5ClkDs0W2lAnKjrW6SBaQB4cEXYpRTK9vlmNsO RLkGITaYWZxltxgMhOwqDV2nhHiag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrledvgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrh hprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeefjeegheetuefhveevudel ueeftdejteeiffetvdduhfdtieefgfeutedtveeggfenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthes vghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Feb 2022 08:06:20 -0500 (EST) Message-ID: <6fdb3ab3-f093-27b9-dfdc-c391e69163fc@enterprisedb.com> Date: Thu, 24 Feb 2022 14:06:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Frontend error logging style Content-Language: en-US To: Tom Lane , Robert Haas Cc: Michael Paquier , PostgreSQL Hackers References: <1363732.1636496441@sss.pgh.pa.us> <632f02ed-12ac-b91f-0e99-9c1b086f8cd0@enterprisedb.com> <913687.1645572199@sss.pgh.pa.us> From: Peter Eisentraut In-Reply-To: <913687.1645572199@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.28 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 23.02.22 00:23, Tom Lane wrote: > This conversation seems to have tailed off without full resolution, > but I observe that pretty much everyone except Peter is on board > with defining pg_log_fatal as pg_log_error + exit(1). So I think > we should just do that, unless Peter wants to produce a finished > alternative proposal. > > I've now gone through and fleshed out the patch I sketched upthread. This patch already illustrates a couple of things that are wrong with this approach: - It doesn't allow any other way of exiting. For example, in pg_dump, you have removed a few exit_nicely() calls. It's not clear why that is valid or whether it would always be valid for all call sites. - It doesn't allow other exit codes. For example, in psql, you have changed a pg_log_fatal() call to pg_log_error() because it needed another exit code. This slides us right back into that annoying situation where in the backend we have to log error messages using elog(LOG) because the flow control is tangled up with the log level. My suggestion is to just get rid of pg_log_fatal() and replace them all with pg_log_error().