Presumably we would want to repeat all of the ordinary commands, in the
file, but not any of the backslash set commands that precede any ordinary
commands. But what if backslash set commands are sprinkled between
ordinary commands?
See, this is why I had no intention of retrying. Since
Josh Berkus j...@agliodbs.com wrote:
I recently had a reason to benchmark a database which is default
SERIALIZABLE mode. I was startled to discover that pgbench is set up to
abort the client once it hits a serialization failure. You get a bunch
of these:
Client 7 aborted in state 11:
On 20.05.2013 14:50, Kevin Grittner wrote:
I raised this issue near the end of SSI development, but nobody
seemed very interested and someone argued that a tool to do that
would be good but we shouldn't try to do it in pgbench -- so I let
it drop at the time.
+1 on doing it in pgbench.
-
On Mon, May 20, 2013 at 4:50 AM, Kevin Grittner kgri...@ymail.com wrote:
I raised this issue near the end of SSI development, but nobody
seemed very interested and someone argued that a tool to do that
would be good but we shouldn't try to do it in pgbench -- so I let
it drop at the time.
I think it would be good to do it in pgbench, provided it can be done
fairly cleanly.
Presumably we would want to repeat all of the ordinary commands, in the
file, but not any of the backslash set commands that precede any ordinary
commands. But what if backslash set commands are sprinkled
Should it give up trying under some conditions, say there are more errors
than transactions?
I don't really see the point of that. I can't think of a scenario where you
would get too many serialization errors to even finish the pgbench test.
My point is really to avoid in principle a
My thinking is that what pgbench should do is:
* track an error count
* if it finds an error, don't increment the transaction count, but do
increment the error count.
* then continue to the next transaction.
Does that seem like the right approach?
Could it retry the *same* transaction
On 2013-05-19 00:03, Fabien COELHO wrote:
My thinking is that what pgbench should do is:
* track an error count
* if it finds an error, don't increment the transaction count, but do
increment the error count.
* then continue to the next transaction.
Does that seem like the right approach?
