Re: pgbench bug candidate: negative "initial connection time"
От | Fujii Masao |
---|---|
Тема | Re: pgbench bug candidate: negative "initial connection time" |
Дата | |
Msg-id | f65cc95b-f6d4-2d1c-9a67-731c198fed23@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: pgbench bug candidate: negative "initial connection time" (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: pgbench bug candidate: negative "initial connection time"
Re: pgbench bug candidate: negative "initial connection time" |
Список | pgsql-hackers |
On 2021/09/24 11:26, Fujii Masao wrote: > > > On 2021/09/24 7:26, Yugo NAGATA wrote: >> That makes sense. Failures of setup connection or initial connection doesn't >> seem 'static problems'. I rewrote this description to explain exit status 1 >> indicates also interal errors and early errors. >> >> Exit status 1 indicates static problems such as invalid command-line options >> or internal errors which are supposed to never occur. Early errors that occur >> when starting benchmark such as initial connection failures also exit with >> status 1. > > LGTM. Barring any objection, I will commit the patch. I extracted two changes from the patch and pushed (also back-patched) them. The remainings are the changes of handling of initial connection or logfile open failures. I agree to push them at least for the master. But I'm not sure if they should be back-patched. Without these changes, even when those failures happen, pgbench proceeds the benchmark and reports the result. But with the changes, pgbench exits immediately in that case. I'm not sure if there are people who expect this behavior, but if there are, maybe we should not change it at least at stable branches. Thought? BTW, when logfile fails to be opened, pgbench gets stuck due to commit aeb57af8e6. So even if we decided not to back-patch those changes, we should improve the handling of logfile open failure, to fix the issue. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: