From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make pgbench exit on SIGINT more reliably |
Date: | 2023-05-24 13:58:46 |
Message-ID: | CSUK7YEFYAFZ.3P26BKFUDTO06@c3po |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue May 23, 2023 at 7:31 PM CDT, Michael Paquier wrote:
> On Mon, May 22, 2023 at 10:02:02AM -0500, Tristan Partin wrote:
> > The way that pgbench handled SIGINT changed in
> > 1d468b9ad81b9139b4a0b16b416c3597925af4b0. Unfortunately this had a
> > couple of unintended consequences, at least from what I can tell[1].
> >
> > - CTRL-C no longer stops the program unless the right point in pgbench
> > execution is hit
> > - pgbench no longer exits with a non-zero exit code
> >
> > An easy reproduction of these problems is to run with a large scale
> > factor like: pgbench -i -s 500000. Then try to CTRL-C the program.
>
> This comes from the code path where the data is generated client-side,
> and where the current CancelRequested may not be that responsive,
> isn't it?
It comes from the fact that CancelRequested is only checked within the
generation of the pgbench_accounts table, but with a large enough scale
factor or enough latency, say cross-continent communication, generating
the other tables can be time consuming too. But, yes you are more likely
to run into this issue when generating client-side data.
--
Tristan Partin
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-05-24 14:15:41 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Previous Message | Bruce Momjian | 2023-05-24 13:58:00 | Re: PG 16 draft release notes ready |