On 2013-01-18 03:05:47 +0900, Fujii Masao wrote: > On Fri, Jan 18, 2013 at 2:35 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2013-01-17 13:47:41 +0900, Michael Paquier wrote: > >> Slave does not try anymore to reconnect to master with messages of the > >> type: > >> FATAL: could not connect to the primary server > >> > >> I also noticed that there is some delay until modifications on master are > >> visible on slave. > > > >> I think that bug has been introduced by commit 7fcbf6a. > >> Before splitting xlog reading as a separate facility things worked > >> correctly. > >> There are also no delay problems before this commit. > > > > Heikki committed a fix for at least the promotion issue, I didn't notice > > any problem with an increased delay, could you check again if you still > > see it? > > 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... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers