Re: pgbench tap tests & minor fixes

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: pgsql-hackers(at)postgresql(dot)org, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: pgbench tap tests & minor fixes
Date: 2017-05-08 16:30:35
Message-ID: 6732427.rPgI264n0q@x200m
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

В письме от 28 апреля 2017 22:39:41 пользователь Fabien COELHO написал:

> Here is a v3, with less files. I cannot say I find it better, but it
> still works.

Actually I like it. It is what I expect it to be ;-)

For me it is more readable then before, as all the data that is used for
testing is on the same screen and I can see it all in one place.

I would also like to hear from Robert, what does he think about it, but I like
the perl code as it is.

> The "command_likes" function has been renamed "command_checks".

This is one thing have my doubts about. There is no way to understand what the
difference between command_likes and command_checks. One can't get while
reading the name. There is no way to understand that these functions do almost
same things, but one of them makes better checks.

My perl experience tells me that this new function should be called
command_likes_more. It is a kind of tradition in test naming things "simple,
more, most, etc". It is not English readable name, but any perl developer will
understand it's meaning.

I would not insist on this. It is a kind of suggestion.

Now to the second part. Now I payed attention to the C part of the patch. And
I have questions and notes.

1. I quite agree with Robert, that this options patch is a separate issue and
it would be better do deal with them separately. But I wild not insist. It
will just made our work on this commit longer, instead of two shorter works.

2. I do not completely understand what you have done in this patch, as this
code is not familiar to me so I would ask questions.

2.1
if (latency_limit)
{
int64 now_us;

if (INSTR_TIME_IS_ZERO(now))
INSTR_TIME_SET_CURRENT(now);
now_us = INSTR_TIME_GET_MICROSEC(now);
while (thread->throttle_trigger < now_us - latency_limit
&&
/* with -t, do not overshoot */
(nxacts <= 0 || st->cnt < nxacts))
{
processXactStats(thread, st, &now, true, agg);
/* next rendez-vous */
wait = getPoissonRand(thread, throttle_delay);
thread->throttle_trigger += wait;
st->txn_scheduled = thread->throttle_trigger;
}

if (nxacts > 0 && st->cnt >= nxacts)
{
st->state = CSTATE_FINISHED;
break;
}
}

First of all I do not completely understand this while and your changes in it.

It is inside doCustom function that is used to run a bunch of transactions.

There is for (;;) in it that is dedicated to run one transaction after
another (it is state machine, so each iteration is one state change, but
several state changes leads to running one transaction after anther
nevertheless)

This while() is inside... Originally It detects that the transaction is late,
"counts" how many throttle_delay will fit in this total delay, and for each
throttle_delay do some logging in processXactStats and counts thread->
latency_late total number there too.

Please note that in original code thread->stats.cnt++; is one only when not
(progress || throttle_delay || latency_limit)

And you've added st->cnt ++; with no conditions. So if transaction is delayed
for N*throttle_delay miliseconds, your st->cnt will be incremented N times.

Are you sure it is what you want to do? If so, I need more explanations
because I do not understand why do you want to count it that way, and what
exactly do you count here.

So more about this while:

Why do you check nxacts > 0? It _must_ be grater then 0.
I think it one want to be sure that some value is valid, he uses Assert.

For me it is like that: if I check using "if" that nxacts > 0 then there is
legal possibility that nxacts has negative value. If i do Assert, there is no
legal possibility for it, but I just want to be sure.

More notes about code styling:

while (thread->throttle_trigger < now_us - latency_limit &&
/* with -t, do not overshoot */
(nxacts <= 0 || st->cnt < nxacts))

and

else
/* just count */
thread->stats.cnt++;

I've do not recall seeing in postgres code new line comments in the middle of
loop condition, and in the middle of if/else statement if there is no {}
there... It seems to me that comments here should go on the same line at the
right. (If I am not right, please fellows, correct me)
May be it is a reason for checking coding style for this case.

The second style issue:

else
thread->stats.cnt++, st->cnt++;

I do not recall using comma operation on cases like these, in postgres code. I
think
else
{
thread->stats.cnt++;
st->cnt++;
}

would be much more readable. (Fellows, please correct me if I am wrong)

As for the comments, there is great utility pg_bsd_indent that goes with
postgres code. You can write comment like

(nxacts <= 0 || st->cnt < nxacts)) /* with -t, do not overshoot */

not caring about the length of the line, and then run pg_bsd_indent. It will
reformat the code as it should be.

--
Nikolay Shaplov, independent Perl & C/C++ developer. Available for hire.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-05-08 16:42:52 Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Peter Eisentraut 2017-05-08 16:28:38 Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression