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:

Reply via email to