From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | nagata(at)sraoss(dot)co(dot)jp, gregsmithpgsql(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, david(dot)christensen(at)crunchydata(dot)com |
Subject: | Re: pgbench logging broken by time logic changes |
Date: | 2021-06-17 07:15:37 |
Message-ID: | alpine.DEB.2.22.394.2106170901100.2693553@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
>>> I cannot say that I'm thrilled by having multiple tv stuff back in several
>>> place. I can be okay with one, though. What about the attached? Does it
>>> make sense?
>
> +1 The patch rounds down sd->start_time from ms to s but it seems to
> me a degradation.
Yes, please we should not use time.
>> At first, I also thought of fixing pg_time_now() to use gettimeofday() instead
>> of INSTR_TIME_SET_CURRENT, but I noticed that using INSTR_TIME_SET_CURRENT is
>> proper to measure time interval. I mean, this macro uses
>> lock_gettime(CLOCK_MONOTONIC, ) if avilable, which give reliable interval
>> timing even in the face of changes to the system clock due to NTP.
>
> If I understand the op correctly, the problem here is the time values
> in pgbench log file are based on a bogus epoch.
It is not "bogus", but is not necessary epoch depending on the underlying
function called behind by INSTR_TIME macros, and people are entitled to
expect epoch for log correlations.
> If it's the only issue
> here and and if we just want to show the time based on the unix epoch
> time, just recording the difference would work as I scketched in the
> attached. (Precisely theepoch would move if we set the system clock
> but I don't think that matters:p)
I do like the approach.
I'm hesitant to promote it for fixing the beta, but the code impact is
small enough, so I'd say yes. Maybe there is a similar issue with progress
which should probably use the same approach. I think that aligning the
implementations can wait for pg15.
The patch as white space issues. Attached an updated version which fixes
that, adds comments and simplify the code a little bit.
> I'm not sure we have transaction lasts for very short time that
> nanoseconds matters.
Indeed.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-epoch-4.patch | text/x-diff | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-06-17 07:18:47 | Re: Two patches to speed up pg_rewind. |
Previous Message | Peter Eisentraut | 2021-06-17 07:08:05 | Re: Python 3.10 breaks regression tests with traceback changes |