On 2013-11-13 08:35:31 +0100, Fabien COELHO wrote:
> >Hello. Attached is a patch that I created against REL9_2_4 for
> >contrib/pgbench. I am willing to re-work the patch for HEAD or another
> >version if you choose to accept the patch.
>
> It rather works the other way around: "you submit a patch which get accepted
> or not, possibly after (too) heavy discussions". It is not "you submit an
> idea, and it gets accepted, and the patch you will submit is applied later
> on". There is a commitfest to submit patches, see
> http://commitfest.postgresql.org.
Well, you certainly can, are even encouraged to, ask for feedback about
a feature before spending significant time on it. So interest certainly
cannot be a guarantee for acceptance, but it certainly is helpful.
> >That background out of the way, here are the additional features:
>
> >--urandom: use /dev/urandom to provide seed values for randomness.
> >Without this, multiple pgbench processes are likely to generate the
> >same sequence of "random" numbers. This was noticeable in InfiniSQL
> >benchmarking because of the resulting extremely high rate of locked
> >records from having stored procedures invoked with identical parameter
> >values.
>
> This loos unix/linux specific? I think that if possible, the randomness
> issue should be kept out of "pgbench"?
urandom is available on a couple of platforms, no just linux. I don't
see a big problem making the current srandom() invocation more complex.
> >-I: do not abort connection if transaction error is encountered.
> >InfiniSQL returns an error if records are locked, so pgbench was
> >patched to tolerate this. This is pending a fix, but until then,
> >pgbench needs to carry on. The specific error emitted from the server
> >is written to stderr for each occurrence. The total quantity of
> >transactions is not incremented if there's an error.
I am not sure I like the implementation not having looked at it, but I
certainly think this is a useful feature. I think the error rate should
be computed instead of just disregarding it though.
It might also be worthwile to add code to automatically retry
transactions that fail with an error indicating a transient error (like
serialization failures).
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
