Re: Make pgbench exit on SIGINT more reliably

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Tristan Partin <[email protected]>
To: Michael Paquier <[email protected]>
To: Yugo NAGATA <[email protected]>
Cc: [email protected]
Subject: Re: Make pgbench exit on SIGINT more reliably
Date: Tue, 27 Jun 2023 09:42:05 -0500
Message-ID: <CTNIFM58WEJ3.KY27ZGKO92J7@gonk> (raw)
In-Reply-To: <[email protected]>
References: <CSSWBAX56CVY.291H6ZNNHK7EO@c3po>
	<[email protected]>
	<CSUK7YEFYAFZ.3P26BKFUDTO06@c3po>
	<[email protected]>
	<CTH123B82H6F.34NSTLQ0XE4AN@gonk>
	<[email protected]>
	<[email protected]>

On Thu Jun 22, 2023 at 6:19 PM CDT, Michael Paquier wrote:
> On Thu, Jun 22, 2023 at 02:58:14PM +0900, Yugo NAGATA wrote:
> > On Mon, 19 Jun 2023 16:49:05 -0700
> > "Tristan Partin" <[email protected]> wrote:
> >> On Mon Jun 19, 2023 at 6:39 AM PDT, Yugo NAGATA wrote:
> >>> [1] https://www.postgresql.org/message-id/flat/CSTU5P82ONZ1.19XFUGHMXHBRY%40c3po
> >> 
> >> The other patch does not replace this one. They are entirely separate.
> > 
> > After applying the other patch, CancelRequested would be checked enough frequently
> > even during initialization of pgbench_branches and pgbench_tellers, and it will
> > allow the initialization step to be cancelled immediately even if the scale factor
> > is high. So, is it unnecessary to modify setup_cancel_handler anyway?
> > 
> > I think it would be still nice to introduce a new exit code for query cancel separately.
>
> I have the same impression as Nagata-san while going again through
> the proposal of this thread.  COPY is more responsive to
> interruptions, and is always going to have a much better performance 
> than individual or multi-value INSERTs for the bulk-loading of data,
> so we could just move on with what's proposed on the other thread and
> solve the problem of this thread on top of improving the loading
> performance.
>
> What are the benefits we gain with the proposal of this thread once we
> switch to COPY as method for the client-side data generation?  If
> the argument is to be able switch to a different error code on
> cancellations for pgbench, that sounds a bit thin to me versus the
> argument of keeping the cancellation callback path as simple as
> possible.

I would say there probably isn't much benefit if you think the polling
for CancelRequested is fine. Looking at the other patch, I think it
might be simple to add an exit code for SIGINT. But I think it might be
best to do it after that patch is merged. I added the other patch to the
commitfest for July. Holding off on this one.

-- 
Tristan Partin
Neon (https://neon.tech)

view thread (10+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Make pgbench exit on SIGINT more reliably
  In-Reply-To: <CTNIFM58WEJ3.KY27ZGKO92J7@gonk>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox