Re: Failing start-up archive recovery at Standby mode in PG9.2.4 - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Date
Msg-id 20130425.103230.130440596.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Kyotaro HORIGUCHI <kyota.horiguchi@gmail.com>)
Responses Re: Failing start-up archive recovery at Standby mode in PG9.2.4
List pgsql-hackers
I had a bit look on it and came up with an hypothesis.. umm or a
scenario.

==
Just after restartpoint, too old xlog files are recycled but its
page header has old content, specifically, xlogid and xrecoff.

Plus, if the master's LSN is at the head of new segment file, the
file for the segment may have not been created and the WAL send
request for that LSN from the standby might fail as "requested
WAL segment %s has already been removed", in spite of the segment
is "not yet created"...
So the standby received nack for the request and looks for
archive but the file is properly not existent. But the file of
that segment is certainly found in pg_xlog directory. So
XLogFileRead grabs the old-in-content file and...

> seems showing that the standby received negative ack for the request
> for 20th segment, and 5 seconds later, it tried to get that from
> archive and somehow thought that it'd gotten but the header is of 6th
> segment.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: danger of stats_temp_directory = /dev/shm
Next
From: Alvaro Herrera
Date:
Subject: Re: danger of stats_temp_directory = /dev/shm