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 d24acd73-bba2-ed50-48f8-1422fc8c0c7c@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-11 09:08, Michael Paquier wrote:
> On Thu, Sep 10, 2020 at 03:59:20PM +0200, Peter Eisentraut wrote:
>> The first patch you proposed checks for errno == ERANGE, but pgbench code
>> doesn't do that.  So one of them is not correct.
> 
> Sorry for the confusion, I misunderstood what you were referring to.
> Yes, the first patch is wrong to add the check on errno.  FWIW, I
> thought about your point to use strtol() but that does not seem worth
> the complication for those tools.  It is not like anybody is going to
> use high values for these, and using uint64 to make sure that the
> boundaries are checked just add more checks for bounds.  There is
> one example in pg_test_timing when compiling the total time.

I didn't mean use strtol() to be able to process larger values, but for 
the error checking.  atoi() cannot detect any errors other than ERANGE. 
So if you are spending effort on making the option value parsing more 
robust, relying on atoi() will result in an incomplete solution.

-- 
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: Collation versioning
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions