From: | Kirk Wolak <wolakk(at)gmail(dot)com> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgbnech: allow to cancel queries during benchmark |
Date: | 2023-06-26 16:59:21 |
Message-ID: | CACLU5mT_etDu7hsH8GWk3DWYRgJgrANUBryHzFCfkZK=xk3Mrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 26, 2023 at 9:46 AM Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:
> Hello,
>
> This attached patch enables pgbench to cancel queries during benchmark.
>
> Formerly, Ctrl+C during benchmark killed pgbench immediately, but backend
> processes executing long queries remained for a while. You can simply
> reproduce this problem by cancelling the pgbench running a custom script
> executing "SELECT pg_sleep(10)".
>
> The patch fixes this so that cancel requests are sent for all connections
> on
> Ctrl+C, and all running queries are cancelled before pgbench exits.
>
> In thread #0, setup_cancel_handler is called before the loop, the
> CancelRequested flag is set when Ctrl+C is issued. In the loop, cancel
> requests are sent when the flag is set only in thread #0. SIGINT is
> blocked in other threads, but the threads will exit after their query
> are cancelled. If thread safety is disabled or OS is Windows, the signal
> is not blocked because pthread_sigmask cannot be used.
> (I didn't test the patch on WIndows yet, though.)
>
> I choose the design that the signal handler and the query cancel are
> performed only in thread #0 because I wanted to make the behavior as
> predicable as possible. However, another design that all thread can
> received SIGINT and that the first thread that catches the signal is
> responsible to sent cancel requests for all connections may also work.
>
> Also, the array of CState that contains all clients state is changed to
> a global variable so that all connections can be accessed within a thread.
>
>
> +1
I also like the thread #0 handling design. I have NOT reviewed/tested
this yet.
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2023-06-26 17:40:49 | Analyze on table creation? |
Previous Message | Nathan Bossart | 2023-06-26 15:51:17 | Re: Clean up JumbleQuery() from query text |