From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz>, "Yugo NAGATA" <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make pgbench exit on SIGINT more reliably |
Date: | 2023-06-27 14:42:05 |
Message-ID: | CTNIFM58WEJ3.KY27ZGKO92J7@gonk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)neon(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2023-06-27 15:00:39 | RE: [PATCH] Reuse Workers and Replication Slots during Logical Replication |
Previous Message | Jonathan S. Katz | 2023-06-27 14:32:27 | PostgreSQL 16 Beta 2 release announcement draft |