Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Date
Msg-id 436d42e9-c59d-6eee-cd42-5902979a749f@2ndquadrant.com
Whole thread Raw
In response to Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 2020-09-23 03:50, Michael Paquier wrote:
> On Tue, Sep 22, 2020 at 11:45:14PM +0200, Peter Eisentraut wrote:
>> However, I still think the integer type use is a bit inconsistent.  In both
>> cases, using strtoul() and dealing with unsigned integer types between
>> parsing and final use would be more consistent.
> 
> No objections to that either, so changed this way.  I kept those
> variables signed because applying values of 2B~4B is not really going
> to matter much here ;p

This patch mixes up unsigned int and uint32 in random ways.  The 
variable is uint32, but the format is %u and the max constant is UINT_MAX.

I think just use unsigned int as the variable type.  There is no need to 
use the bit-exact types.  Note that the argument of alarm() is of type 
unsigned int.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist