Comparing primary/HS standby in tests - Mailing list pgsql-hackers

From Andres Freund
Subject Comparing primary/HS standby in tests
Date
Msg-id 20150303154922.GB7579@alap3.anarazel.de
Whole thread Raw
Responses Re: Comparing primary/HS standby in tests  (Michael Paquier <michael.paquier@gmail.com>)
Re: Comparing primary/HS standby in tests  (Jeff Janes <jeff.janes@gmail.com>)
Re: [HACKERS] Comparing primary/HS standby in tests  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

I've regularly wished we had automated tests that setup HS and then
compare primary/standby at the end to verify replay worked
correctly.

Heikki's page comparison tools deals with some of that verification, but
it's really quite expensive and doesn't care about runtime only
differences. I.e. it doesn't test HS at all.

I every now and then run installcheck against a primary, verify that
replay works without errors, and then compare pg_dumpall from both
clusters. Unfortunately that currently requires hand inspection of
dumps, there are differences like:
-SELECT pg_catalog.setval('default_seq', 1, true);
+SELECT pg_catalog.setval('default_seq', 33, true);

The reason these differences is that the primary increases the
sequence's last_value by 1, but temporarily sets it to +SEQ_LOG_VALS
before XLogInsert(). So the two differ.

Does anybody have a good idea how to get rid of that difference? One way
to do that would be to log the value the standby is sure to have - but
that's not entirely trivial.

I'd very much like to add a automated test like this to the tree, but I
don't see wa way to do that sanely without a comparison tool...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: "Syed, Rahila"
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Next
From: Andres Freund
Date:
Subject: Re: autogenerated column names + views are a dump hazard