On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI
> At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier
> <michael.paqu...@gmail.com> wrote in
>> > 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
> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: