Re: pgbench's expression parsing & negative numbers - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench's expression parsing & negative numbers
Date
Msg-id alpine.DEB.2.20.1712120702000.10431@lancre
Whole thread Raw
In response to pgbench's expression parsing & negative numbers  (Andres Freund <andres@anarazel.de>)
Responses Re: pgbench's expression parsing & negative numbers
List pgsql-hackers
Hello Andres,

> working on overflow correctness in pg I noticed that pgbench isn't quite
> there.  I assume it won't matter terribly often, but the way it parses
> integers makes it incorrect for, at least, the negativemost number.
>
> It directly parses the integer input using:
> {digit}+        {
>                     yylval->ival = strtoint64(yytext);
>                     return INTEGER_CONST;
>                 }
>
> but that unfortunately means that the sign is no included in the call to
> strtoint64. Which in turn means you can't correctly parse PG_INT64_MIN,

Indeed. For a benchmarking script which generates a pseudo random load I 
do not see as a big issue, but maybe I'm missing some use case.

> because that's not representable as a positive number on a two's 
> complement machine (i.e. everywhere).  Preliminary testing shows that 
> that can relatively easily fixed by just prefixing [-+]? to the relevant 
> exprscan.l rules.

Beware that it must handle the unary/binary plus/minus case consistently:

   "-123" vs "a -123" vs "a + -123"

> But it might also not be a bad idea to simply defer parsing of the 
> number until exprparse.y has its hand on the number?

It is usually simpler to let the lexer handle constants.

> There's plenty other things wrong with overflow handling too, especially 
> evalFunc() basically just doesn't care.

Sure.

There are some overflow checking with div and double to int cast, which 
were added because of previous complaints, but which are not very useful 
to me.

ISTM that it is a voluntary feature, which handles int64 operations 
with a modulo overflow like C. Generating exceptions on such overflows 
does not look very attractive to me.

>  I'll come up with a patch for that sometime soon.

I wish you could provide some motivation: why does it matter much to a 
benchmarking script to handle overflows with more case?

> A third complaint I have is that the tap tests are pretty hard to parse
> for humans.

Probably.

Perl is pretty hard to humans to start with:-)

There is a lot of code factorization to cram many tests together, so that 
one test is more or less one line and there are hundreds of them. Not sure 
it would help if it was expanded.

There are a lot of regular expressions to check outputs, which does not 
help.

I wanted to have the pgbench scripts outside but this has been rejected, 
so the tested scripts themselves are in the middle of the perl code, which 
I think has degraded the readability significantly.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Using ProcSignal to get memory context stats from a running backend
Next
From: Craig Ringer
Date:
Subject: Re: Using ProcSignal to get memory context stats from a running backend