Re: Error on pgbench logs
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Michael Paquier <michael@paquier.xyz>,
Kyotaro Horiguchi
<horikyota.ntt@gmail.com>, rulyox@gmail.com,
PostgreSQL Developers
<pgsql-hackers@lists.postgresql.org>
Date: 2021-06-12T18:27:42Z
Lists: pgsql-hackers
On Thu, 10 Jun 2021 23:29:30 +0200 (CEST) Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > Bonjour Michaël, > > Here is an updated patch. While having a look at Kyotaro-san patch, I > noticed that the aggregate stuff did not print the last aggregate. I think > that it is a side effect of switching the precision from per-second to > per-µs. I've done an attempt at also fixing that which seems to work. This is just out of curiosity. + while ((next = agg->start_time + agg_interval * INT64CONST(1000000)) <= now) I can find the similar code to convert "seconds" to "us" using casting like end_time = threads[0].create_time + (int64) 1000000 * duration; or next_report = last_report + (int64) 1000000 * progress; Is there a reason use INT64CONST instead of (int64)? Do these imply the same effect? Sorry, if this is a dumb question... Regards, Yugo Nagata -- Yugo NAGATA <nagata@sraoss.co.jp>
Commits
-
Fix pgbench timestamp bugs.
- 5614a0f78eaa 14.0 landed
- 0e39a608ed55 15.0 landed
-
pgbench: Improve time logic.
- 547f04e7348b 14.0 cited
-
Make [U]INT64CONST safe for use in #if conditions.
- 9d6b160d7db7 11.0 cited
-
Teach libpq to detect integer overflow in the row count of a PGresult.
- 2e70d6b5e99b 11.0 cited