Re: Error on pgbench logs
От | Fabien COELHO |
---|---|
Тема | Re: Error on pgbench logs |
Дата | |
Msg-id | alpine.DEB.2.22.394.2106150828380.1864934@pseudo обсуждение исходный текст |
Ответ на | Re: Error on pgbench logs (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Error on pgbench logs
Re: Error on pgbench logs |
Список | pgsql-hackers |
Hello Michaël, >> I think we don't have to call doLog() before logAgg(). If we call doLog(), >> we will count an extra transaction that is not actually processed because >> accumStats() is called in this. > > Yes, calling both is weird. The motivation to call doLog is to catch up zeros on slow rates, so as to avoid holes in the log, including at the end of the run. This "trick" was already used by the code. I agree that it would record a non existant transaction, which is not desirable. I wanted to avoid a special parameter, but this seems unrealistic. > Is using logAgg() directly in the context actually right when it comes > to sample_rate? The point is just to trigger the last display, which is not triggered by the previous I think because of the precision: the start of the run is not exactly the start of the thread. > We may not log anything on HEAD if sample_rate is enabled, but we would > finish by logging something all the time with this patch. I do not get it. > If I am following this code correctly, we don't care about accumStats() > in the code path of a thread we are done with, right? Yes. Attached a v3 which adds a boolean to distinguish recording vs flushing. -- Fabien.
В списке pgsql-hackers по дате отправления: