On 2017-05-26 10:29, Mark Kirkwood wrote:
On 26/05/17 20:09, Erik Rijkers wrote:

On 2017-05-26 09:40, Simon Riggs wrote:

If we can find out what the bug is with a repeatable test case we can fix it.

Could you provide more details? Thanks

I will, just need some time to clean things up a bit.


But what I would like is for someone else to repeat my 100x1-minute tests, taking as core that snippet I posted in my previous email. I built bash-stuff around that core (to take md5's, shut-down/start-up the two instances between runs, write info to log-files, etc). But it would be good if someone else made that separately because if that then does not fail, it would prove that my test-harness is at fault (and not logical replication).


Will do - what I had been doing was running pgbench, waiting until the

Great!

You'll have to think about whether to go with instances of either master, or master+those 4 patches. I guess either choice makes sense.

row counts on the replica pgbench_history were the same as the
primary, then summing the %balance and delta fields from the primary
and replica dbs and comparing. So far - all match up ok. However I'd

I did number-summing for a while as well (because it's a lot faster than taking md5's over the full content). But the problem with summing is that (I think) in the end you cannot be really sure that the result is correct (false positives, although I don't understand the odds).

been running a longer time frames (5 minutes), so not the same number
of repetitions as yet.

I've run 3600-, 30- and 15-minute runs too, but in this case (these 100x tests) I wanted to especially test the area around startup/initialise of logical replication. Also the increasing quality of logical replication (once it runs with the correct

thanks,

Erik Rijkers


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to