Re: Error on pgbench logs - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Error on pgbench logs
Date
Msg-id alpine.DEB.2.22.394.2106150828380.1864934@pseudo
Whole thread Raw
In response to Re: Error on pgbench logs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Error on pgbench logs  (Yugo NAGATA <nagata@sraoss.co.jp>)
Re: Error on pgbench logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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 by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Use singular number when appropriate
Next
From: Yugo NAGATA
Date:
Subject: Re: Error on pgbench logs