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" <tris...@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)
