On 2017-05-26 08:58, Simon Riggs wrote:
On 26 May 2017 at 07:10, Erik Rijkers <e...@xs4all.nl> wrote:
- Do you agree this number of failures is far too high?
- Am I the only one finding so many failures?
What type of failure are you getting?
The failure is that in the result state the replicated tables differ
from the original tables.
For instance,
-- out_20170525_0944.txt
100 -- pgbench -c 90 -j 8 -T 60 -P 12 -n -- scale 25
93 -- All is well.
7 -- Not good.
These numbers mean: the result state of primary and replica is not the
same, in 7 out of 100 runs.
'not the same state' means: at least one of the 4 md5's of the sorted
content of the 4 pgbench tables on the primary is different from those
taken from the replica.
So, 'failure' means: the 4 pgbench tables on primary and replica are not
exactly the same after the (one-minute) pgbench-run has finished, and
logical replication has 'finished'. (plenty of time is given for the
replica to catchup. The test only calls 'failure' after 20x waiting (for
15 seconds) and 20x finding the same erroneous state (erroneous because
not-same as on primary).
I would really like to know it you think that that doesn't amount to
'failure'.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
