Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration

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

In response to

Responses

Browse pgsql-hackers by date

  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