Re: Failing start-up archive recovery at Standby mode in PG9.2.4

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org
Cc: andres(at)2ndquadrant(dot)com, kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp
Subject: Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Date: 2013-04-25 01:32:30
Message-ID: 20130425.103230.130440596.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-04-25 01:42:45 Re: danger of stats_temp_directory = /dev/shm
Previous Message Jeff Janes 2013-04-24 23:12:05 danger of stats_temp_directory = /dev/shm