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.=replica
Please 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.
sent_20170527_1745.tar.bz2
Description: BZip2 compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
