From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
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-06 03:04:26 |
Message-ID: | 20200906030426.GA2086@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
pgtest-fix-range-v2.patch | text/x-diff | 6.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2020-09-06 11:05:35 | Re: Improving connection scalability: GetSnapshotData() |
Previous Message | Justin Pryzby | 2020-09-06 01:12:31 | Re: Multivariate MCV list vs. statistics target |