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

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Дата
Msg-id 20130425.103230.130440596.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Kyotaro HORIGUCHI <kyota.horiguchi@gmail.com>)
Ответы Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Amit Langote <amitlangote09@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: danger of stats_temp_directory = /dev/shm
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: danger of stats_temp_directory = /dev/shm