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-15T08:15:14Z
Lists: pgsql-hackers
On Tue, 15 Jun 2021 10:05:29 +0200 (CEST) Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > Hello Michaël, > > >> I think we don't have to call doLog() before logAgg(). If we call doLog(), > >> we will count an extra transaction that is not actually processed because > >> accumStats() is called in this. > > > > Yes, calling both is weird. > > The motivation to call doLog is to catch up zeros on slow rates, so as to > avoid holes in the log, including at the end of the run. This "trick" was > already used by the code. I agree that it would record a non existant > transaction, which is not desirable. I wanted to avoid a special > parameter, but this seems unrealistic. > > > Is using logAgg() directly in the context actually right when it comes > > to sample_rate? > > The point is just to trigger the last display, which is not triggered by > the previous I think because of the precision: the start of the run is > not exactly the start of the thread. > > > We may not log anything on HEAD if sample_rate is enabled, but we would > > finish by logging something all the time with this patch. > > I do not get it. It was not a problem because --sampling-rate --aggregate-interval cannot be used at the same time. > > If I am following this code correctly, we don't care about accumStats() > > in the code path of a thread we are done with, right? > > Yes. > > Attached a v3 which adds a boolean to distinguish recording vs flushing. Sorry, but I can't find any patach attached... -- 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