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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Дата
Msg-id 20200906030426.GA2086@paquier.xyz
обсуждение исходный текст
Ответ на Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Список pgsql-hackers
On Fri, Sep 04, 2020 at 11:24:39PM +0200, Peter Eisentraut wrote:
> According to the POSIX standard, atoi() is not required to do any error
> checking, and if you want error checking, you should use strtol().
>
> And if you do that, you might as well change the variables to unsigned and
> use strtoul(), and then drop the checks for <=0.

Switching to unsigned makes sense, indeed.

> I would allow 0. It's not
> very useful, but it's not harmful and could be applicable in testing.

Hmm, OK.  For pg_test_fsync, 0 means infinity, and for pg_test_timing
that means stopping immediately (we currently don't allow that).  How
does this apply to testing?  For pg_test_fsync, using 0 would mean to
just remain stuck in the first fsync() pattern, while for
pg_test_fsync this means doing no test loops at all, generating a
useless log once done.  Or do you mean to change the logic of
pg_test_fsync so as --secs-per-test=0 means doing one single write?
That's something I thought about for this thread, but I am not sure
that the extra regression test gain is worth more complexity in this
code.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Improving connection scalability: GetSnapshotData()