Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave - Mailing list pgsql-hackers

Hi all,<br /><br />There is a strange bug with the latest master head (commit 7fcbf6a).<br />When the WAL stream with a
masteris cut on a slave, slave returns a FATAL (well normal...), but then enters in recovery process and automatically
promotes.<br/> Here are more details about the logs on slave (I simply killed the master manually):<br />FATAL:  could
notreceive data from WAL stream:<br />cp: cannot stat
‘/home/michael/bin/pgsql/archive/master/000000010000000000000004’:No such file or directory<br /> LOG:  record with
zerolength at 0/401E1B8<br />LOG:  redo done at 0/401E178<br />LOG:  last completed transaction was at log time
2013-01-1720:27:53.180971+09<br />cp: cannot stat ‘/home/michael/bin/pgsql/archive/master/00000002.history’: No such
fileor directory<br /> LOG:  selected new timeline ID: 2<br />cp: cannot stat
‘/home/michael/bin/pgsql/archive/master/00000001.history’:No such file or directory<br />LOG:  archive recovery
complete<br/>DEBUG:  resetting unlogged relations: cleanup 0 init 1<br /> LOG:  database system is ready to accept
connections<br/>LOG:  autovacuum launcher started<br />DEBUG:  archived transaction log file
"000000010000000000000004"<br/>DEBUG:  archived transaction log file "00000002.history"<br /> LOG:  statement: create
tablebn (a int);<br />DEBUG:  autovacuum: processing database "postgres"<br /><br />Slave does not try anymore to
reconnectto master with messages of the type:<br />FATAL:  could not connect to the primary server<br /><br />I also
noticedthat there is some delay until modifications on master are visible on slave.<br />For example run a simple
CREATETABLE and the new table is not <br /><br />[some bisecting later...]<br /><br />I think that bug has been
introducedby commit 7fcbf6a.<br />Before splitting xlog reading as a separate facility things worked correctly.<br
/>Thereare also no delay problems before this commit.<br /><br />Does someone else noticed that?<br />-- <br />Michael
Paquier<br/><a href="http://michael.otacoo.com" target="_blank">http://michael.otacoo.com</a> 

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: CF3+4 (was Re: Parallel query execution)
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: CF3+4