Hi hackers! Recently Kirill and I did some benchmarks with --log and --aggregate-interval and noticed inaccuracy: transactions that fall into the last, not-yet-closed interval are silently omitted from the log. doLog() only emits intervals that have fully elapsed, and the flush done at the end of a run walks the same fully-elapsed intervals - so the tail is dropped without any warning.
Deterministic reproducer: $ pgbench -i -s 1 pq $ pgbench -c 1 -t 60 -n -l --aggregate-interval=5 -f onetx.sql pq number of transactions actually processed: 60/60 $ cat pgbench_log.* # empty! POC-patch of the accounting fix attached, it does: - the interval-printing code is split into printAggInterval() (print one row), flushElapsedAggIntervals() (loop over completed intervals, shared by doLog() and the shutdown flush) - at shutdown, flushElapsedAggIntervals() first flushes the fully elapsed intervals, then the final, possibly partial interval is written as well, when it collected any data (aggIntervalHasData()) - a new TAP test asserts that a run much shorter than the interval logs exactly one row accounting for all processed transactions Any feedback would be appreciated! -- Best regards, Roman Khapov
0001-pgbench-log-the-final-partial-interval-with-aggregat.patch
Description: Binary data
