Re: Switching timeline over streaming replication

On Thursday, November 15, 2012 6:05 PM Heikki Linnakangas wrote:
> On 15.11.2012 12:44, Heikki Linnakangas wrote:
> > Here's an updated version of this patch, rebased with master,
> > including the recent replication timeout changes, and some other
> cleanup.
> >
> > On 12.10.2012 09:34, Amit Kapila wrote:
> >> The test is finished from myside.
> >>
> >> one more issue:
> >  > ...
> >> ./pg_basebackup -P -D ../../data_sub -X fetch -p 2303
> >> pg_basebackup: COPY stream ended before last file was finished
> >
> > Fixed this.
> >
> > However, the test scenario you point to here:
> > http://archives.postgresql.org/message-id/00a801cda6f3$4aba27b0$e02e77
> > 10$@kapila@huawei.com still seems to be broken, although I get a
> > different error message now.
> > I'll dig into this..
> 
> Ok, here's an updated patch again, with that bug fixed.

First, I started with test of this Patch.

Basic stuff: 
------------ 
- Patch applies OK 
- Compiles cleanly with no warnings 
- Regression tests pass except the "standbycheck". 

From a glance view of the "standbycheck" regression failures are because of
sql scripts and expected outputs are little old. 

The following problems are observed while testing of the patch. 
Defect-1: 
     1. start primary A      2. start standby B following A      3. start cascade standby C following B.      4.
Promotestandby B.      5. After successful time line switch in cascade standby C, stop C.      6. Restart C, startup is
failingwith the following error. 
 
       LOG:  database system was shut down in recovery at 2012-11-16
16:26:29 IST        FATAL:  requested timeline 2 does not contain minimum recovery point
0/30143A0 on timeline 1        LOG:  startup process (PID 415) exited with exit code 1        LOG:  aborting startup
dueto startup process failure 
 

The above defect is already discussed in the following link. 
http://archives.postgresql.org/message-id/00a801cda6f3$4aba27b0$e02e7710$@ka
pila@huawei.com 



Defect-2: 
     1. start primary A      2. start standby B following A      3. start cascade standby C following B with
'recovery_target_timeline'
option in          recovery.conf is disabled.      4. Promote standby B.      5. Cascade Standby C is not able to
followthe new master B because of
 
timeline difference.        6. Try to stop the cascade standby C (which is failing and the
server is not stopping,          observations are as WAL Receiver process is still running and
clients are not allowing to connect).

The defect-2 is happened only once in my test environment, I will try to
reproduce it.

With Regards,
Amit Kapila.