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 | e9636ae9-850d-856d-3656-0eaa26273bb6@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-20 05:41, Michael Paquier wrote: > On Fri, Sep 18, 2020 at 05:22:15PM +0900, Michael Paquier wrote: >> Okay, after looking at that, here is v3. This includes range checks >> as well as errno checks based on strtol(). What do you think? > > This fails in the CF bot on Linux because of pg_logging_init() > returning with errno=ENOTTY in the TAP tests, for which I began a new > thread: > https://www.postgresql.org/message-id/20200918095713.GA20887@paquier.xyz > > Not sure if this will lead anywhere, but we can also address the > failure by enforcing errno=0 for the new calls of strtol() introduced > in this patch. So here is an updated patch doing so. I think the error checking is now structurally correct in this patch. However, I still think the integer type use is a bit inconsistent. In both cases, using strtoul() and dealing with unsigned integer types between parsing and final use would be more consistent. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: