Re: Error on pgbench logs
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, rulyox@gmail.com,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-09T07:46:10Z
Lists: pgsql-hackers
Hello Michael, >> The cause is that the time unit is changed to usec but the patch >> forgot to convert agg_interval into the same unit in doLog. I tempted >> to change it into pg_time_usec_t but it seems that it is better that >> the unit is same with other similar variables like duration. > > As the option remains in seconds, I think that it is simpler to keep > it as an int, and do the conversion where need be. It would be good > to document that agg_interval is in seconds where the variable is > defined. > > - while (agg->start_time + agg_interval <= now) > + while (agg->start_time + agg_interval * 1000000 <= now) > > In need of a cast with (int64), no? Yes, it would be better. In practice I would not expect the interval to be large enough to trigger an overflow (maxint µs is about 36 minutes). > The other things are "progress" and "duration". These look correctly > handled to me. Hmmm… What about tests? I'm pretty sure that I wrote a test about time sensitive features with a 2 seconds run (-T, -P, maybe these aggregates as well), but the test needed to be quite loose so as to pass on slow/heavy loaded hosts, and was removed at some point on the ground that it was somehow imprecise. I'm not sure whether it is worth to try again. -- Fabien.
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