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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Дата
Msg-id 517947F2.7010904@vmware.com
обсуждение исходный текст
Ответ на 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  (Kyotaro HORIGUCHI <kyota.horiguchi@gmail.com>)
Список pgsql-hackers
On 25.04.2013 17:55, Kyotaro HORIGUCHI wrote:
> Hmm. I think that I caught the tail of the problem..
>
> Script with small change reproduced the situation for me.

Can you share the modified script, please?

> The latest standby uses 3 as its TLI after the history file
> 0..3.history which could get from the archive. So the WAL files
> recycled on this standby will have the TLI=3.
> Nevertheless the LSN of the segment recycled on standby is on the
> TLI=2 in the master, the standby makes the first request for each
> segment with that LSN but TLI = 3 to the master because the standby
> runs on recoveryTargetTLI=3. The master reasonably doesn't have it and
> finally the standby finds that wrong WAL file in its pg_xlog directory
> before the second request with TLI=2 would be made.

I'm not sure I understand what the problem is, though. When the standby 
opens the bogus, recycled, file in pg_xlog, it will notice that the 
header is incorrect, and retry reading the file from the archive.

> In conclusion, the standby should name the recycled WAL segment using
> the same TLI for the LSN on the master. Or should never recycle WAL
> files..

Perhaps, but it should nevertheless not get confused by recycled segments.

- Heikki



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Proposal to add --single-row to psql
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: putting a bgworker to rest