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  (Yugo NAGATA <nagata@sraoss.co.jp>)
Re: Error on pgbench logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Use singular number when appropriate
Следующее
От: Yugo NAGATA
Дата:
Сообщение: Re: Error on pgbench logs