Re: pgbench tap tests & minor fixes

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: pgbench tap tests & minor fixes
Date: 2017-05-08 21:17:49
Message-ID: alpine.DEB.2.20.1705082307580.3983@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

> st->cnt -- number of transactions finished successed or failed, right?

Or *skipped*. That is why I changed the declaration comment.

> one iteration of for(;;) is for one transaction or really less. Right?

No, under -R -L late schedules are simply skipped.

> We can't process two tansactions in one iteration of this loop. So we
> can't increase st->cnt more then once during one iteration?

Yes we can, if they are skipped because the scheduling was too late to
execute them on time.

> processXactStats(thread, st, &now, true, agg);
>
> Let's imagine that thread->throttle_trigger is now_us - 10 000,
> latency_limit is 5 000 and throttle_delay is 100
>
> How many times you would call processXactStats in this while loop?

Around 100 times to catch up.

> And each time it would do st->cnt++

Yep. The "true" argument tells the stats that the transaction was skipped,
though. It just counting late transaction that could not be processed.

> And this while loop is inside for(;;) in which as I said above we can do
> st->cnt++ not more than once. I see no logic here.

The logic is that at most one *real* transaction is actually performed in
the for, but there may be any number of "skipped" (unexecuted) ones, which
is fine.

> PS This is a fast reply. May be it will make things clear fast wither for me
> or for you. I will carefully answer your full letter tomorrow (I hope nothing
> will prevent me from doing it)

Today was a holiday in France. Tomorrow is not.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2017-05-08 21:27:32 Re: Google Summer Of Code 2017 & PostgreSQL
Previous Message Peter Eisentraut 2017-05-08 21:01:00 Re: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)