Comparing primary/HS standby in tests

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Comparing primary/HS standby in tests
Дата
Msg-id 20150303154922.GB7579@alap3.anarazel.de
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "Syed, Rahila"
Дата:
Сообщение: Re: [REVIEW] Re: Compression of full-page-writes
Следующее
От: Andres Freund
Дата:
Сообщение: Re: autogenerated column names + views are a dump hazard