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 1m86O4-00072L-Jj for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Jul 2021 19:35:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m86O3-0006ur-4k for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Jul 2021 19:35:39 +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 1m86O2-0006uj-T4 for pgsql-hackers@lists.postgresql.org; Mon, 26 Jul 2021 19:35:38 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m86O0-0003fp-Nh for pgsql-hackers@lists.postgresql.org; Mon, 26 Jul 2021 19:35:37 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 479FB320093C; Mon, 26 Jul 2021 15:35:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 26 Jul 2021 15:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=YoizBNkPt/1ZKE9Wzq7oYqbOyDNsTStaFjMovvgdHnE=; b=noo7uPiM FCnEx+Mnyq/SE9HY6k4ot2+xcf8dk/ZlrxkwEVc3i3roBhcubX5p4cfzySQLVnxB jJBoB/RLuVRy85A0bYKGrIBLCugcJ25ZB9imoRmA6i7yB7cNiB5LCGSFM3jA2lvR lJv/+/cDkB1bZsRfBhsPQlHiWjEeMYN2ufS+TaN9okRHRC2vdlDA5DHj1YzjUDpI PeGT9t8ks5L9iQXc8Z5iPWId7GOUaJqEpD5SUmwGdDBhVPeTxrMQTxLCMlN/dluS faZ9IzKYBfMK/60cnkbSkUcknAVZD1SFEmDBu8y9Yft6+S+atEciAbqCKUA3zY5k YOzBo5GT+FzQgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeehgddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 26 Jul 2021 15:35:32 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 97EC12A06A7; Mon, 26 Jul 2021 15:35:29 -0400 (-04) Date: Mon, 26 Jul 2021 15:35:29 -0400 From: Alvaro Herrera To: Fabien COELHO Cc: Michael Paquier , Postgres hackers Subject: Re: Some code cleanup for pgbench and pg_verifybackup Message-ID: <202107261935.tad2ojwemn3v@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Jul-26, Fabien COELHO wrote: > > - pgbench and pg_verifybackup make use of pg_log_fatal() to report > > some failures in code paths dedicated to command-line options, which > > is inconsistent with all the other tools that use pg_log_error(). > > The semantics for fatal vs error is that an error is somehow handled while a > fatal is not. If the log message is followed by an cold exit, ISTM that > fatal is the right call, and I cannot help if other commands do not do that. > ISTM more logical to align other commands to fatal when appropriate. I was surprised to discover a few weeks ago that pg_log_fatal() did not terminate the program, which was my expectation. If every single call to pg_log_fatal() is followed by exit(1), why not make pg_log_fatal() itself exit? Apparently this coding pattern confuses many people -- for example pg_verifybackup.c lines 291ff fail to exit(1) after "throwing" a fatal error, while the block at lines 275 does the right thing. (In reality we cannot literally just exit(1) in pg_log_fatal(), because there are quite a few places that do some other thing after the log call and before exit(1), or terminate the program in some other way than exit().) -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ Essentially, you're proposing Kevlar shoes as a solution for the problem that you want to walk around carrying a loaded gun aimed at your foot. (Tom Lane)