RE: pgbench: option delaying queries till connections establishment?
От | Fabien COELHO |
---|---|
Тема | RE: pgbench: option delaying queries till connections establishment? |
Дата | |
Msg-id | alpine.DEB.2.22.394.2011111316540.3832060@pseudo обсуждение исходный текст |
Ответ на | RE: pgbench: option delaying queries till connections establishment? ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: pgbench: option delaying queries till connections establishment?
|
Список | pgsql-hackers |
Hello, >> I can remove the line, but I strongly believe that reporting performance >> figures if some client connection failed thus the bench could not run as >> prescribed is a bad behavior. The good news is that it is probably quite >> unlikely. So I'd prefer to keep it and possibly submit a patch to change >> the behavior. > > I agree such a situation is very bad, and I understood you have a plan to > submit patches for fix it. If so leaving lines as a TODO is OK. Thanks. >> Should be this one: https://commitfest.postgresql.org/30/2624/ > > This discussion is still on-going, but I can see that the starting time > may be delayed for looking up all pgbench-variables. Yep, that's it. > (I think the status of this thread might be wrong. it should be > 'Needs review,' but now 'Waiting on Author.') I changed it to "Needs review". > This patch is mostly good and can change a review status soon, > however, I think it should wait that related patch. Hmmm. > Please discuss how to fix it with Tom, I would not have the presumption to pressure Tom's agenda in any way! > and this will commit soon. and this will wait till its time comes. In the mean time, I think that you should put the patch status as you see fit, independently of the other patch: it seems unlikely that they would be committed together, and I'll have to merge the remaining one anyway. -- Fabien.
В списке pgsql-hackers по дате отправления: