Search Postgresql Archives

Re: Recovery_target_time misinterpreted?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

To me it indicates that log file 000000010000026400000002 might be corrupt.

PostgreSQL stops replaying WAL after it detects a corrupt WAL record.

Do you have a second copy of the WAL file?

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux