Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date
Msg-id alpine.DEB.2.02.1306142033530.10940@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
List pgsql-hackers
Hello Greg,

I think that the weirdness really comes from the way transactions times 
are measured, their interactions with throttling, and latent bugs in the 
code.

One issue is that the throttling time was included in the measure, but not 
the first time because "txn_begin" is not set at the beginning of 
doCustom.

Also, flag st->listen is set to 1 but *never* set back to 0... sh> grep listen pgbench.c        int
listen;       if (st->listen)                        st->listen = 1;                        st->listen = 1;
          st->listen = 1;                        st->listen = 1;                                st->listen = 1;
                      st->listen = 1;
 

ISTM that I can fix the "weirdness" by inserting an ugly "goto top;", but 
I would feel better about it by removing all gotos and reordering some 
actions in doCustom in a more logical way. However that would be a bigger 
patch.

Please find attached 2 patches:
 - the first is the full throttle patch which ensures that the   txn_begin is taken at a consistent point, after
throttling,  which requires resetting "listen". There is an ugly goto.   I've also put times in a consistent format in
thelog,   "789.012345" instead of "789 12345".
 
 - the second patch just shows the diff between v10 and the first one.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SPGist "triple parity" concept doesn't work
Next
From: Greg Smith
Date:
Subject: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)