Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id 20160108.135322.121365974.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.

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?

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.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_conversion seems rather strangely defined
Next
From: Etsuro Fujita
Date:
Subject: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW)