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" <tristan@neon.tech> 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)