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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
