Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
Date: 2013-01-17 19:57:28
Message-ID: 50F857A8.7080800@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.01.2013 20:08, Andres Freund wrote:
> On 2013-01-18 03:05:47 +0900, Fujii Masao wrote:
>> I encountered the problem that the timeline switch is not performed expectedly.
>> I set up one master, one standby and one cascade standby. All the servers
>> share the archive directory. restore_command is specified in the recovery.conf
>> in those two standbys.
>>
>> I shut down the master, and then promoted the standby. In this case, the
>> cascade standby should switch to new timeline and replication should be
>> successfully restarted. But the timeline was never changed, and the following
>> log messages were kept outputting.
>>
>> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1
>> sby2 LOG: replication terminated by primary server
>> sby2 DETAIL: End of WAL reached on timeline 1
>> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1
>> sby2 LOG: replication terminated by primary server
>> sby2 DETAIL: End of WAL reached on timeline 1
>> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1
>> sby2 LOG: replication terminated by primary server
>> sby2 DETAIL: End of WAL reached on timeline 1
>> ....
>
> That's after the commit or before? Because in passing I think I
> noticed/fixed a bug that could cause exactly that problem...

I think I broke that with the "teach pg_receivexlog to cross timelines"
patch. Will take a look...

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-01-17 19:58:41 Re: Removing PD_ALL_VISIBLE
Previous Message Tom Lane 2013-01-17 19:51:28 Re: could not create directory "...": File exists