Re: Make pgbench exit on SIGINT more reliably
От | Tristan Partin |
---|---|
Тема | Re: Make pgbench exit on SIGINT more reliably |
Дата | |
Msg-id | CSUK7YEFYAFZ.3P26BKFUDTO06@c3po обсуждение исходный текст |
Ответ на | Re: Make pgbench exit on SIGINT more reliably (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Make pgbench exit on SIGINT more reliably
|
Список | 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)
В списке pgsql-hackers по дате отправления: