Re: pgbench bug candidate: negative "initial connection time"
От | Fabien COELHO |
---|---|
Тема | Re: pgbench bug candidate: negative "initial connection time" |
Дата | |
Msg-id | alpine.DEB.2.22.394.2106141108240.1338009@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench bug candidate: negative "initial connection time" (Yugo NAGATA <nagata@sraoss.co.jp>) |
Ответы |
Re: pgbench bug candidate: negative "initial connection time"
|
Список | pgsql-hackers |
>>> Hmmm. Possibly. Another option could be not to report anything after some >>> errors. I'm not sure, because it would depend on the use case. I guess the >>> command returned an error status as well. >> >> I did not know any use cases and decisions , but I vote to report nothing when error occurs. > > I would prefer to abort the thread whose connection got an error and report > results for other threads, as handled when doConnect fails in CSTATE_START_TX > state. It is unclear to me whether it makes much sense to report performance when things go wrong. At least when a one connection per client bench is run ISTM that it should not proceed, because the bench could not even start as prescribe. When connection break while the bench has already started, maybe it makes more sense to proceed, although I guess that maybe reattempting connections would make also sense in such case. > In this case, we have to set the state to CSTATE_ABORT before going to 'done' > as fixed in the attached patch, in order to ensure that exit status is 2 and the > result reports "pgbench: fatal: Run was aborted; the above results are incomplete." Hmmm. I agree that at least reporting that there was an issue is a good idea. > Otherwise, if we want pgbench to exit immediately when a connection error occurs, > we have tocall exit(1) to ensure the exit code is 1, of course. Anyway, it is wrong > that thecurrent pgbench exit successfully with exit code 0 when doConnnect fails. Indeed, I can only agree on this one. -- Fabien.
В списке pgsql-hackers по дате отправления: