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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Дата
Msg-id d24acd73-bba2-ed50-48f8-1422fc8c0c7c@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Collation versioning
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions