Re: Support for N synchronous standby servers - take 2
От | Michael Paquier |
---|---|
Тема | Re: Support for N synchronous standby servers - take 2 |
Дата | |
Msg-id | CAB7nPqT9rsxyV1UTiW-1o-O5BTTwxTj3uGmnuL-Byj_bZ3OCdg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for N synchronous standby servers - take 2 (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Support for N synchronous standby servers - take 2
|
Список | pgsql-hackers |
On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > Hello, > > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in <CAB7nPqTp5RoHxcp8YxejGMjRjjtLaXCa8=-BEr7ZnBNbPzPdWA@mail.gmail.com> >> > Attached latest v5 patch. >> > Please review it. >> >> 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. > This patch mainly changes the logic to choose the next syncrep > standbys and calculate the 'synched' LSNs, so performing separate > module tests for the logics, then perform the test for the > behavior according to the result of that by, perhaps, > PostgresNode.pm would remarkably reduce the labor for > testing. > Could we have some tapping point for individual testing of the > logics in appropriate way? Isn't pg_stat_replication enough for this purpose? What you basically need to do is set up a master, a set of slaves and then look at the WAL sender status. Am I getting that wrong? > In order to do so, the logics should be able to be fed arbitrary > complete set of parameters, in other words, defining a kind of > API to use the logics from the core side, even though it is not > an extension. Then we will *somehow* kick the API with some set > of parameters in regest. Well, you will need to craft in the syncrep test suite associated in this patch a set of routines that allows to set up appropriately s_s_names and the other parameters that this patch introduces. I does not sound like a barrier impossible to cross. -- Michael
В списке pgsql-hackers по дате отправления: