Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing
Date
Msg-id CAHGQGwGtRyX4Qrr-6XkFGpNxcdGs-gBuv4Cqqyco9+kict+j+A@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas@postgresql.org> wrote:
>>> pg_test_timing utility, to measure clock monotonicity and timing cost.
>>
>> When I compiled this, I got a compiler warning. Attached patch
>> silences the warning.
>
> Unfortunately, that *produces* a warning on my machine.  Normally, I
> think we handle this using INT64_FORMAT, but the fact that it's %10ld
> here and not just %lld makes that awkward.  I guess we maybe need to
> insert some kludgy workaround here - write it into a separate buffer,
> and then blank-pad it, or something like that.

This seems a simplest workaround. How about attached patch?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
Next
From: Noah Misch
Date:
Subject: Re: 9.2 commitfest closure (was Command Triggers, v16)