| From: | Roman Khapov <rkhapov(at)yandex-team(dot)ru> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | pgbench aggregates final part can be missed at log |
| Date: | 2026-10-31 17:37:07 |
| Message-ID: | 33CB487B-A60D-4FEA-A211-07801744B771@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-pgbench-log-the-final-partial-interval-with-aggregat.patch | application/octet-stream | 7.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Paul A Jungwirth | 2026-10-31 17:20:22 | Reject wholerow references where ColumnRef is forbidden |