Re: pgbnech: allow to cancel queries during benchmark

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbnech: allow to cancel queries during benchmark
Date: 2023-09-06 11:13:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi Fabien,

On Thu, 10 Aug 2023 12:32:44 +0900
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:

> On Wed, 9 Aug 2023 11:18:43 +0200 (CEST)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> >
> > I forgot, about the test:
> >
> > I think that it should be integrated in the existing
> > "" script, because a TAP script is pretty
> > expensive as it creates a cluster, starts it… before running the test.
> Ok. I'll integrate the test into 001.
> > I'm surprise that IPC::Run does not give any access to the process number.
> > Anyway, its object interface seems to allow sending signal:
> >
> > $h->signal("...")
> >
> > So the code could be simplified to use that after a small delay.
> Thank you for your information.
> I didn't know $h->signal() and I mimicked the way of
> src/bin/psql/t/ to send SIGINT to a running program. I don't
> know why the psql test doesn't use the interface, I'll investigate whether
> this can be used in our purpose, anyway.

I attached the updated patch v3. The changes since the previous
patch includes the following;

I removed the unnecessary condition (&& false) that you
pointed out in [1].

The test was rewritten by using IPC::Run signal() and integrated
to "". This test is skipped on Windows
because SIGINT causes to terminate the test itself as discussed
in [2] about query cancellation test in psql.

I added some comments to describe how query cancellation is
handled as I explained in [1].

Also, I found the previous patch didn't work on Windows so fixed it.
On non-Windows system, a thread waiting a response of long query can
be interrupted by SIGINT, but on Windows, threads do not return from
waiting until queries they are running are cancelled. This is because,
when the signal is received, the system just creates a new thread to
execute the callback function specified by setup_cancel_handler, and
other thread continue to run[3]. Therefore, the queries have to be
cancelled in the callback function.


Yugo Nagata

> --
> Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
v3_pgbench_query_cancel.patch text/x-diff 6.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2023-09-06 11:32:33 Re: Transaction timeout
Previous Message Peter Eisentraut 2023-09-06 11:02:50 Re: information_schema and not-null constraints