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
|
Список | 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 по дате отправления: