On 2017-05-27 17:11, Andres Freund wrote:
> On May 27, 2017 6:13:19 AM EDT, Simon Riggs <simon@2ndquadrant.com>
> wrote:
>> On 27 May 2017 at 09:44, Erik Rijkers <er@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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
