Re: extend pgbench expressions with functions

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2016-01-14 05:26:31
Message-ID: CAB7nPqS_J+JcGUQ8ssd0sGTA6P3FG7nrb9kZJA=ZG3g8Lf+RPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 13, 2016 at 10:28 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> Hello Michaël,
>
>>> ISTM that if pgbench is to be stopped, the simplest option is just to
>>> abort
>>> with a nicer error message from the get*Rand function, there is no need
>>> to
>>> change the function signature and transfer the error management upwards.
>>
>>
>> That's fine to me, as long as the solution is elegant.
>
>
> Hmmm, this is subjective:-)

And dependent on personal opinions and views.

> I've decided to stay with the current behavior (\setrandom), that is to
> abort the current transaction on errors but not to abort pgbench itself. The
> check is done before calling the functions, and I let an assert in the
> functions just to be sure. It is going to loop on errors anyway, but this is
> what it already does anyway.

OK, yes I see now I missed that during my last review. This has the
disadvantage to double the amount of code dedicated to parameter
checks though :(
But based on the feedback perhaps other folks would feel that it would
be actually worth simply dropping the existing \setrandom command. I
won't object to that personally, such pgbench features are something
for hackers and devs mainly, so I guess that we could survive without
a deprecation period here.

>>> Ok. I'm hesitating about removing the operator management, especially if
>>> I'm
>>> told to put it back afterwards.
>>
>>
>> I can understand that, things like that happen all the time here and
>> that's not a straight-forward patch that we have here. I am sure that
>> additional opinions here would be good to have before taking one
>> decision or another. With the current statu-quo, let's just do what
>> you think is best.
>
>
> I let the operators alone and just adds functions management next to it.
> I'll merge operators as functions only if it is a blocker.

I think that's a blocker, but I am not the only one here and not a committer.

- fprintf(stderr, "gaussian parameter must be at least
%f (not \"%s\")\n", MIN_GAUSSIAN_PARAM, argv[5]);
+ fprintf(stderr,
+ "random gaussian parameter must be greater than %f "
+ "(got %f)\n", MIN_GAUSSIAN_PARAM, parameter);
This looks like useless noise to me. Why changing those messages?

- if (parameter <= 0.0)
+ if (parameter < 0.0)
{

This bit is false, and triggers an assertion failure when the
exponential parameter is 0.

fprintf(stderr,
- "exponential parameter must be greater than
zero (not \"%s\")\n",
- argv[5]);
+ "random exponential parameter must be greater than 0.0 "
+ "(got %f)\n", parameter);
st->ecnt++;
- return true;
+ return false;
This diff is noise as well, and should be removed.

+ /*
+ * Note: this section could be removed, as the same
functionnality
+ * is available through \set xxx random_gaussian(...)
+ */
I think that you are right to do that. That's no fun to break existing
scripts, even if people doing that with pgbench are surely experienced
hackers.

}
-
case ENODE_VARIABLE:
Such diffs are noise as well.

int() should be strengthened regarding bounds. For example:
\set cid debug(int(int(9223372036854775807) +
double(9223372036854775807)))
debug(script=0,command=1): int -9223372036854775808
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-01-14 05:38:35 Removing service-related code in pg_ctl for Cygwin
Previous Message Michael Paquier 2016-01-14 04:27:33 Re: Python 3.x versus PG 9.1 branch