Re: Print pgbench results on SIGINT

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Roman Khapov <rkhapov(at)yandex-team(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Print pgbench results on SIGINT
Date: 2026-10-27 09:07:11
Message-ID: CALdSSPhmwR4__7QpY2fU5knOd41cGPb9RtsL+KedVHyBGMiuxA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 26 Oct 2026 at 11:42, Roman Khapov <rkhapov(at)yandex-team(dot)ru> wrote:
>
> Hi hackers!

Hi

> While working on [1] or [2] I sometimes use pgbench in short-run mode:
> see if there is some performance improvements or degradation for 5-10 seconds,
> press CTRL+C, make some code changes and repeat the measurements.
>
> For now, pgbench prints nothing on CTRL+C, which hides the run statistics
> from user. What if it printed the collected statistics anyway, along with the
> existing 'Run was aborted; the above results are incomplete.' message?
>
> Attached POC-patch does:
> - on first SIGINT stops accepting new transactions, discards the in-flight ones
> and print the summary as usual, exiting with status 130
> - on second SIGINT fallbacks to standard handler immediately
> - caps all wait at one second, so the SIGINT can interrupt the \sleep

I think this enhances UX for manual testing/measurements, so overall
im +1 on this. Double ctrl^C kills pgbench instantly which I think is
good decision.

There is however a small bug where workers can submit new commands
after the stop flag is set.
The flag is checked once at the top of the outer threadRun loop, but a
worker whose EINTR check was missed can go through a full iteration of
the state machine after the flag changes. This can make a few
transactions to reach the server. Maybe we should check
aborted_by_sigint in more places

> For now I am not sure about exit code..

There was an earlier related thread "Make pgbench exit on SIGINT more
reliably" [0] which may contain useful context on Windows handling.

[0] https://www.postgresql.org/message-id/CSSWBAX56CVY.291H6ZNNHK7EO@c3po

--
Best regards,
Kirill Reshke

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message David Steele 2026-10-27 08:46:49 Re: Avoid truncated or zero-padded copies of replaced files in backups.