Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKlEK-00BveT-1s for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jun 2024 20:51:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sKlEI-009ng0-7S for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jun 2024 20:51:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKlEH-009nXT-Tt for pgsql-hackers@lists.postgresql.org; Fri, 21 Jun 2024 20:51:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKlE9-002soV-DU for pgsql-hackers@postgresql.org; Fri, 21 Jun 2024 20:51:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 45LKpF6S647661; Fri, 21 Jun 2024 16:51:15 -0400 From: Tom Lane To: Hannu Krosing cc: Peter Eisentraut , "Andrey M. Borodin" , pgsql-hackers Subject: Re: What is a typical precision of gettimeofday()? In-reply-to: References: <47AEACEE-E5CC-40E4-8611-01F3A465AF16@yandex-team.ru> <9e7b21e7-4c63-4299-87f4-780a0699a7d8@eisentraut.org> <130996.1718814994@sss.pgh.pa.us> Comments: In-reply-to Hannu Krosing message dated "Thu, 20 Jun 2024 12:41:54 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <647659.1719003075.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 2024 16:51:15 -0400 Message-ID: <647660.1719003075@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hannu Krosing 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 =E2=80=98output=E2=80=99: [19:24:31.951] pg_test_timing.c:229:11: error: format =E2=80=98%ld=E2=80=99= expects argument of type =E2=80=98long int=E2=80=99, but argument 3 has t= ype =E2=80=98int64=E2=80=99 {aka =E2=80=98long long int=E2=80=99} [-Werror= =3Dformat=3D] [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 C4= 067: unexpected tokens following preprocessor directive - expected a newli= ne regards, tom lane [1] https://commitfest.postgresql.org/48/5066/ [2] http://cfbot.cputube.org/highlights/all.html#5066