Re: What is a typical precision of gettimeofday()?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hannu Krosing <hannuk@google.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
"Andrey M. Borodin" <x4mmm@yandex-team.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-06-21T20:51:15Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Force LC_NUMERIC to C while running TAP tests.
- f25792c541e5 19 (unreleased) landed
-
Minor tweaks for pg_test_timing.
- 9dcc7641444f 19 (unreleased) landed
-
Change pg_test_timing to measure in nanoseconds not microseconds.
- 0b096e379e6f 19 (unreleased) landed
Hannu Krosing <hannuk@google.com> writes:
> This is my current patch which also adds running % and optionally uses
> faster way to count leading zeros, though I did not see a change from
> that.
I've not read the patch yet, but I did create a CF entry [1]
to get some CI cycles on this. The cfbot complains [2] about
[19:24:31.951] pg_test_timing.c: In function ‘output’:
[19:24:31.951] pg_test_timing.c:229:11: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int64’ {aka ‘long long int’} [-Werror=format=]
[19:24:31.951] 229 | printf("%*ld %*.4f %*.4f %*lld\n",
[19:24:31.951] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[19:24:31.951] 230 | Max(8, len1), i,
[19:24:31.951] | ~
[19:24:31.951] | |
[19:24:31.951] | int64 {aka long long int}
which seems a bit confused, but anyway you cannot assume that int64 is
a match for "%ld", or "%lld" either. What we generally do for this
elsewhere is to explicitly cast printf arguments to long long int.
Also there's this on Windows:
[19:23:48.231] ../src/bin/pg_test_timing/pg_test_timing.c(162): warning C4067: unexpected tokens following preprocessor directive - expected a newline
regards, tom lane
[1] https://commitfest.postgresql.org/48/5066/
[2] http://cfbot.cputube.org/highlights/all.html#5066