Re: Recovery_target_time misinterpreted?

Поиск
Список
Период
Сортировка
От Klaus Ita
Тема Re: Recovery_target_time misinterpreted?
Дата
Msg-id CAK9oVJyP48F_R5r-NZ3nkchvT4bCruusEr-7aMmcum8=LhPOdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovery_target_time misinterpreted?  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Ответы Re: Recovery_target_time misinterpreted?  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Список pgsql-general
2013-07-30 11:15:15 UTC <%> LOG:  starting point-in-time recovery to 2013-07-27 21:20:17.127664+00
2013-07-30 11:15:15 UTC <%> LOG:  restored log file "00000001000002300000005C" from archive
2013-07-30 11:15:15 UTC <%> LOG:  restored log file "00000001000002300000005A" from archive
2013-07-30 11:15:15 UTC <%> LOG:  redo starts at 230/5ACD7CC0
...
...
...
2013-07-30 14:28:45 UTC <%> LOG:  restored log file "000000010000026400000002" from archive
2013-07-30 14:28:45 UTC <%> LOG:  unexpected pageaddr 263/C706C000 in log file 612, segment 2, offset 442368
2013-07-30 14:28:45 UTC <%> LOG:  redo done at 264/20698A8
2013-07-30 14:28:45 UTC <%> LOG:  last completed transaction was at log time 2013-07-18 11:42:22.121512+00
2013-07-30 14:28:45 UTC <%> LOG:  restored log file "000000010000026400000002" from archive
cp: cannot stat `/var/tmp/xlogs_recovered_2013-07-30/wal_files/00000002.history*': No such file or directory
mv: cannot stat `/tmp/00000002.history': No such file or directory
2013-07-30 14:28:45 UTC <%> LOG:  selected new timeline ID: 2
cp: cannot stat `/var/tmp/xlogs_recovered_2013-07-30/wal_files/00000001.history*': No such file or directory
mv: cannot stat `/tmp/00000001.history': No such file or directory
2013-07-30 14:28:45 UTC <%> LOG:  archive recovery complete
2013-07-30 14:29:09 UTC <%> LOG:  autovacuum launcher started
2013-07-30 14:29:09 UTC <%> LOG:  database system is ready to accept connections


well, that does not indicate anything for me.



On Wed, Jul 31, 2013 at 9:37 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
Klaus Ita wrote:
> I have restored a Database Cluster with a recovery_target_time set to
>
> recovery_target_time =  '2013-07-27 21:20:17.127664+00'
> recovery_target_inclusive = false
>
>
>
> now it seems the restore rather restored to some point in time (rather the 18th than the 27th). Is
> there an explanation for this huge gap? Is that the last 'consistent state'?

Maybe the log entries created during restore can answer the question.

Yours,
Laurenz Albe

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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, re-installation failure PLEASE CAN SOMEONE HELP!!
Следующее
От: Rob Sargent
Дата:
Сообщение: Re: more fun with building 9.3beta2