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 1odQfw-0008CB-2l for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Sep 2022 06:36:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1odQfu-0002kz-Ui for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Sep 2022 06:36:06 +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 1odQfu-0002kq-LG for pgsql-hackers@lists.postgresql.org; Wed, 28 Sep 2022 06:36:06 +0000 Received: from dd25110.kasserver.com ([85.13.146.49]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odQfs-0005nx-1f for pgsql-hackers@lists.postgresql.org; Wed, 28 Sep 2022 06:36:06 +0000 Received: from [192.168.0.52] (ip-037-201-153-193.um10.pools.vodafone-ip.de [37.201.153.193]) by dd25110.kasserver.com (Postfix) with ESMTPSA id 61473E1A0160; Wed, 28 Sep 2022 08:36:02 +0200 (CEST) Message-ID: <481f228c-ce59-355a-ff48-202d50d30d54@technowledgy.de> Date: Wed, 28 Sep 2022 08:36:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 From: walther@technowledgy.de Subject: Re: Make ON_ERROR_STOP stop on shell script failure To: Fujii Masao , bt22nakamorit , Kyotaro Horiguchi Cc: pgsql-hackers@lists.postgresql.org References: <20220916.173035.322733707258561235.horikyota.ntt@gmail.com> <4c61d434cb72b2237b3279797b2a387f@oss.nttdata.com> <8a022f2c8de93ea79116f0b7eb42248a@oss.nttdata.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Fujii Masao: > One concern about this patch is that some applications already depend on > the current behavior of ON_ERROR_STOP, i.e., psql doesn't stop even when > the shell command returns non-zero exit code. If so, we might need to > extend ON_ERROR_STOP so that it accepts the following setting values. I just got bitten by this and I definitely consider this a bug. I expect psql to stop when a shell script fails and I have ON_ERROR_STOP set. I don't think this should be made more complicated with different settings. If someone needs to have ON_ERROR_STOP set, but continue execution after a certain shell command, they could still do something like this: \! might_fail || true Best Wolfgang