On Fri, Sep 25, 2020 at 07:52:10AM +0200, Peter Eisentraut wrote:
> looks good to me
Thanks, applied.
--
Michael
signature.asc
Description: PGP signature
On 2020-09-24 09:12, Michael Paquier wrote:
On Wed, Sep 23, 2020 at 08:11:59AM +0200, Peter Eisentraut wrote:
This patch mixes up unsigned int and uint32 in random ways. The variable is
uint32, but the format is %u and the max constant is UINT_MAX.
I think just use unsigned int as the
On Wed, Sep 23, 2020 at 08:11:59AM +0200, Peter Eisentraut wrote:
> This patch mixes up unsigned int and uint32 in random ways. The variable is
> uint32, but the format is %u and the max constant is UINT_MAX.
>
> I think just use unsigned int as the variable type. There is no need to use
> the
On 2020-09-23 03:50, Michael Paquier wrote:
On Tue, Sep 22, 2020 at 11:45:14PM +0200, Peter Eisentraut wrote:
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
On Tue, Sep 22, 2020 at 11:45:14PM +0200, Peter Eisentraut wrote:
> 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.
No objections to that either,
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
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
On Tue, Sep 15, 2020 at 02:39:08PM +0200, Peter Eisentraut wrote:
> 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,
>
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
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
On 2020-09-10 09:59, Michael Paquier wrote:
I notice that the error checking you introduce is different from the checks
for pgbench -t and -T (the latter having no errno checks). I'm not sure
which is correct, but it's perhaps worth making them the same.
pgbench currently uses atoi() to parse
On Mon, Sep 07, 2020 at 10:06:57AM +0200, Peter Eisentraut wrote:
> However, I see that in the case of pg_test_fsync you end up in alarm(0),
> which does something different, so it's okay in that case to disallow it.
Yep.
> I notice that the error checking you introduce is different from the
On 2020-09-06 05:04, Michael Paquier wrote:
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
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
On 2020-08-06 08:27, Michael Paquier wrote:
As $subject says, pg_test_fsync and pg_test_timing don't really check
the range of option values specified. It is possible for example to
make pg_test_fsync run an infinite amount of time, and pg_test_timing
does not handle overflows with --duration
Hi all,
As $subject says, pg_test_fsync and pg_test_timing don't really check
the range of option values specified. It is possible for example to
make pg_test_fsync run an infinite amount of time, and pg_test_timing
does not handle overflows with --duration at all.
These are far from being
16 matches
Mail list logo
