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 CAM103DszApkBTib2tDmyNHJ_vfRyXnZBu-PwKRYsFyzhzowhcg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Oops,

> But thats not what happening here, afaics the "restore log file ..."
> message is only printed if the returncode is 0.

You're right. 'cp <nonexistent> <somewhere>' exits with the status
code 1 (or 256?).

The quoted log lines simply show that segment for tli=3 did not exist
and that for tli=2 had been gotten finally. It's quite normal and
irrelevant to the trouble mentioned. Sorry for the confusion.

Unfortunately, the script attached didn't reproduce the situation for
me. But in the log attached,

> [Standby] 2013-04-22 01:27:25 EDTFATAL:  XX000: could not receive data from WAL stream: FATAL:  requested WAL segment
000000030000000000000014has already been removed
 
> cp: cannot stat `../arc/000000030000000000000014': No such file or directory.
> [Standby] 2013-04-22 01:27:30 EDTDEBUG:  00000: unexpected pageaddr 0/6000000 in log file 0, segment 20, offset 0

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.

regards,

-- 
Kyotaro Horiguchi



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: GSOC Student Project Idea