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

Hi all,

There is a strange bug with the latest master head (commit 7fcbf6a).
When the WAL stream with a master is cut on a slave, slave returns a FATAL
(well normal...), but then enters in recovery process and automatically
promotes.
Here are more details about the logs on slave (I simply killed the master
manually):
FATAL:  could not receive data from WAL stream:
cp: cannot stat
‘/home/michael/bin/pgsql/archive/master/000000010000000000000004’: No such
file or directory
LOG:  record with zero length at 0/401E1B8
LOG:  redo done at 0/401E178
LOG:  last completed transaction was at log time 2013-01-17
20:27:53.180971+09
cp: cannot stat ‘/home/michael/bin/pgsql/archive/master/00000002.history’:
No such file or directory
LOG:  selected new timeline ID: 2
cp: cannot stat ‘/home/michael/bin/pgsql/archive/master/00000001.history’:
No such file or directory
LOG:  archive recovery complete
DEBUG:  resetting unlogged relations: cleanup 0 init 1
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
DEBUG:  archived transaction log file "000000010000000000000004"
DEBUG:  archived transaction log file "00000002.history"
LOG:  statement: create table bn (a int);
DEBUG:  autovacuum: processing database "postgres"

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.
For example run a simple CREATE TABLE and the new table is not

[some bisecting later...]

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.

Does someone else noticed that?
-- 
Michael Paquier
http://michael.otacoo.com