Re: Recovery_target_time misinterpreted?

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(dot)albe(at)wien(dot)gv(dot)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
>