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 1lz24k-00030l-Ob for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 19:10:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lz24i-0003wn-PV for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 19:10:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lz24i-0003vP-HS for pgsql-hackers@lists.postgresql.org; Thu, 01 Jul 2021 19:10:12 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lz24g-0002N1-HQ for pgsql-hackers@postgresql.org; Thu, 01 Jul 2021 19:10:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 161JA5sA748145; Thu, 1 Jul 2021 15:10:05 -0400 From: Tom Lane To: Peter Eisentraut cc: Jacob Champion , "daniel@yesql.se" , "pgsql-hackers@postgresql.org" , "michael@paquier.xyz" Subject: Re: Preventing abort() and exit() calls in libpq In-reply-to: References: <3128896.1624742969@sss.pgh.pa.us> <18eda75d-af6d-3fc0-03b6-607eff9f392a@enterprisedb.com> <622907.1625084114@sss.pgh.pa.us> <630837.1625092151@sss.pgh.pa.us> <67ddcb26f82acaffb26c59b7d8e4cd75399b2cd3.camel@vmware.com> <9d35a4ac-2c75-cb44-95ab-61d69deb072e@enterprisedb.com> <745046.1625163264@sss.pgh.pa.us> Comments: In-reply-to Peter Eisentraut message dated "Thu, 01 Jul 2021 21:03:58 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <748143.1625166605.1@sss.pgh.pa.us> Date: Thu, 01 Jul 2021 15:10:05 -0400 Message-ID: <748144.1625166605@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > On 01.07.21 20:14, Tom Lane wrote: >> The problem then is, what happens when the extra action fails? >> Without .DELETE_ON_ERROR, the shlib is still there and the next >> make run will think everything's good. > Right. .DELETE_ON_ERROR is already set in Makefile.global, so it's not > necessary to set it again. Right. Since we use that, we don't actually have that problem. What we'd have instead is that debugging an unexpected failure of the "extra action" would be painful, because there would be no way short of modifying the Makefiles to create its input data. So I think the other solution with a separate rule is better. regards, tom lane