On Wed, Jan 13, 2016 at 1:54 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Michael Paquier wrote: >> On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> > Hello, >> > >> > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier >> > <michael.paqu...@gmail.com> wrote in >> > <CAB7nPqTp5RoHxcp8YxejGMjRjjtLaXCa8=-ber7znbnbpzp...@mail.gmail.com> >> >> >> >> Something that I find rather scary with this patch: could it be >> >> possible to get actual regression tests now that there is more >> >> machinery with PostgresNode.pm? As syncrep code paths get more and >> >> more complex, so are debugging and maintenance. >> > >> > The test on the whole replication system will very likely to be >> > too complex and hard to stabilize, and would be >> > disproportionately large to other tests. >> >> I don't buy that much. Mind you, there is in this commit fest a patch >> introducing a basic regression test suite for recovery using the new >> infrastructure that has been committed last month. You may want to >> look at it. > > Kyotaro, please have a look at this patch: > https://commitfest.postgresql.org/8/438/ > which is the recovery test framework Michael is talking about. Is it > possible to use that framework to write tests for this feature? If so, > then my preferred course of action would be to commit that patch and > then introduce in this patch some additional tests for the N-sync-standby > feature. Can you please have a look at the test framework patch and > provide your feedback on how usable it is for this? >
I had a look that patch. I'm planning to have at least following tests for multiple synchronous replication. * Confirm value of pg_stat_replication.sync_state (sync, async or potential) * Confirm that the data is synchronously replicated to multiple standbys in same cases. * case 1 : The standby which is not listed in s_s_name, is down * case 2 : The standby which is listed in s_s_names but potential standby, is down * case 3 : The standby which is considered as sync standby, is down. * Standby promotion In order to confirm that the commit isn't done in case #3 forever unless new sync standby is up, I think we need the framework that cancels executing query. That is, what I'm planning is, 1. Set up master server (s_s_name = '2, standby1, standby2) 2. Set up two standby servers 3. Standby1 is down 4. Create some contents on master (But transaction is not committed) 5. Cancel the #4 query. (Also confirm that the flush location of only standby2 makes progress) Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
