From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration |
Date: | 2020-09-15 12:39:08 |
Message-ID: | d24acd73-bba2-ed50-48f8-1422fc8c0c7c@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-09-15 12:42:48 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Peter Eisentraut | 2020-09-15 12:27:38 | Re: Collation versioning |