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.2106110832270.3886726@pseudo
Whole thread Raw
In response to Re: Error on pgbench logs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Error on pgbench logs
List pgsql-hackers
Bonjour Michaël,

>> +        /* flush remaining stats */
>> +        if (!logged && latency == 0.0)
>> +            logAgg(logfile, agg);
>
> You are right, this is missing the final stats.  Why the choice of
> latency here for the check?

For me zero latency really says that there is no actual transaction to 
count, so it is a good trigger for the closing call. I did not wish to add 
a new "flush" parameter, or a specific function. I agree that it looks 
strange, though.

> That's just to make the difference between the case where doLog() is 
> called while processing the benchmark for the end of the transaction and 
> the case where doLog() is called once a thread ends, no?

Yes.

> Wouldn't it be better to do a final push of the states once a thread 
> reaches CSTATE_FINISHED or CSTATE_ABORTED instead?

The call was already in place at the end of threadRun and had just become 
ineffective. I did not wish to revisit its place and change the overall 
structure, it is just a bug fix. I agree that it could be done differently 
with the added logAgg function which could be called directly. Attached 
another version which does that.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_regress.c also sensitive to various PG* environment variables
Next
From: Tom Lane
Date:
Subject: Re: recovery test failures on hoverfly