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 1nzglw-00042j-0G for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Jun 2022 15:42:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzglu-00074H-TZ for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Jun 2022 15:42:02 +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 1nzglu-000748-LE for pgsql-bugs@lists.postgresql.org; Fri, 10 Jun 2022 15:42:02 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzgls-0003Cy-Eb for pgsql-bugs@lists.postgresql.org; Fri, 10 Jun 2022 15:42:01 +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 25AFfntG2649418; Fri, 10 Jun 2022 11:41:49 -0400 From: Tom Lane To: Michael Paquier cc: Kyotaro Horiguchi , christoph.berg@credativ.de, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error In-reply-to: References: <20220531.113927.640026319524742851.horikyota.ntt@gmail.com> <20220603.175603.682874096867945240.horikyota.ntt@gmail.com> Comments: In-reply-to Michael Paquier message dated "Mon, 06 Jun 2022 11:15:44 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2649416.1654875709.1@sss.pgh.pa.us> Date: Fri, 10 Jun 2022 11:41:49 -0400 Message-ID: <2649417.1654875709@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Fri, Jun 03, 2022 at 05:56:03PM +0900, Kyotaro Horiguchi wrote: >>> It causes psql to issue a BEGIN command before the first such option >>> and a COMMIT command after the last one, thereby wrapping all the >>> commands into a single transaction. >>> If any of the commands fails, a ROLLBACK command is sent instead. >>> This ensures that either all the commands complete successfully, or >>> no changes are applied. > Looks fine to me, so applied down to 10. While preparing release notes, I had to study this commit to figure out what it actually did, and I do not think it is right yet. It definitely does not do what is claimed above, ie rollback if "any" of the steps fails. As coded, it rolls back only if the *last* step fails. Now, if you've got ON_ERROR_STOP set, then the loop terminates after an error so there's no difference ... but if you do not, I think this behavior is not what's expected. ISTM that an appropriate fix would be to remember if any command failed, not just the last one. regards, tom lane