pgbench vs. SERIALIZABLE

Hackers,

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: ERROR:  could not serialize access due to
read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during write.
HINT:  The transaction might succeed if retried.
Client 0 aborted in state 11: ERROR:  could not serialize access due to
read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during write.

... which continue until you're down to one client, which then finished
out the pgbench (at very low rates, of course).

The problem is this code here:
               if (commands[st->state]->type == SQL_COMMAND)               {                       /*
                        * Read and discard the query result; note this
is not included in                        * the statement latency numbers.
                        */                       res = PQgetResult(st->con);                       switch
(PQresultStatus(res))                      {                               case PGRES_COMMAND_OK:
       case PGRES_TUPLES_OK:                                       break;          /* OK */
 default:                                       fprintf(stderr, "Client %d
 
aborted in state %d: %s",                                                       st->id,
st->state, PQerrorMessage(st->con));                                       PQclear(res);
      return clientDone(st, false);                       }                       PQclear(res);
discard_response(st);


The way I read that, if the client encounters any errors at all, it
gives up and halts that client.  This doesn't seem very robust, and it
certainly won't work with SERIALIZABLE.

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?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com