| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, rulyox(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Error on pgbench logs |
| Date: | 2021-06-11 14:09:10 |
| Message-ID: | alpine.DEB.2.22.394.2106110832270.3886726@pseudo |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| pgbench-log-fix-2.patch | text/x-diff | 2.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-06-11 14:37:21 | Re: recovery test failures on hoverfly |
| Previous Message | Alvaro Herrera | 2021-06-11 14:08:20 | Re: pg_regress.c also sensitive to various PG* environment variables |