Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-06T03:04:26Z
Lists: pgsql-hackers
Attachments
- pgtest-fix-range-v2.patch (text/x-diff) patch v2
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
Commits
-
Improve range checks of options for pg_test_fsync and pg_test_timing
- 4d29e6dbd0bb 14.0 landed