On 2017-05-27 17:11, Andres Freund wrote:
On May 27, 2017 6:13:19 AM EDT, Simon Riggs <si...@2ndquadrant.com> wrote:On 27 May 2017 at 09:44, Erik Rijkers <e...@xs4all.nl> wrote:I am very curious at your results.We take your bug report on good faith, but we still haven't seen details of the problem or how to recreate it. Please post some details. Thanks.?
ok, ok... ( The thing is, I am trying to pre-digest the output but it takes time )I can do this now: attached some output that belongs with this group of 100 1-minute runs:
-- out_20170525_1426.txt 100 -- pgbench -c 64 -j 8 -T 60 -P 12 -n -- scale 25 82 -- All is well. 18 -- Not good. That is the worst set of runs of what I showed earlier. that is: out_20170525_1426.txt and 2x18 logfiles that the 18 failed runs produced. Those logfiles have names like: logrep.20170525_1426.1436.1.scale_25.clients_64.NOK.log logrep.20170525_1426.1436.2.scale_25.clients_64.NOK.log .1.=primary .2.=replicaPlease disregard the errors around pg_current_wal_location(). (it was caused by some code to dump some wal into zipfiles which obviously stopped working after the function was removed/renamed) There are also some uninportant errors from the test-harness where I call with the wrong port. Not interesting, I don't think.
Description: BZip2 compressed data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers