Date: Mon, 06 Jun 2022 15:11:24 +0900 (JST)
Message-Id: <20220606.151124.656806001979080471.horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: 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
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <Yp1jUAVnyYfn80vu@paquier.xyz>
References: <YphNHbOkg22H7d52@paquier.xyz>
	<20220603.175603.682874096867945240.horikyota.ntt@gmail.com>
	<Yp1jUAVnyYfn80vu@paquier.xyz>
User-Agent: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20220606.151124.656806001979080471.horikyota.ntt%40gmail.com>
Precedence: bulk

At Mon, 6 Jun 2022 11:15:44 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Fri, Jun 03, 2022 at 05:56:03PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 2 Jun 2022 14:39:41 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> >> 001_basic.pl, but we also need to be careful when sending down queries
> >> with psql expected to fail because of SIGPIPE (c757a3d, 6d41dd0).  The
> > 
> > This does not need to send a byte after the client-side failure. The
> > connection is rather living after failure in this case.
> 
> Sure, but I don't think that we can reliably test the case where one
> of the switches triggers a backend-side error, which is what my point
> is about.  I have added a note about that, with a couple of extra
> tests with -f, with both success and failure scenarios.  And we'd
> better add -X to all the commands as well.  These are added only on
> HEAD as the test file is rather new.

Mmm, sorry about my laziness, and thanks for improving the coverage.

> >> 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.

(Yes!)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center