<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I was able to find the file, which was from the date of the failure
(Tuesday June 9th). My question is why the backup from this morning
would all of a sudden require a file from the 9th even though 5 hours
of logs were able to be applied? I ended up doing another hotbackup and
restoring the database from this afternoon and this seems to be working
fine. I am just worried that another WAL file will throw the same error
and I will be without a warm standby.<br>
<br>
Thanks again,<br>
<br>
Keith<br>
<br>
Tom Lane wrote:
<blockquote cite="mid:22090(dot)1245092382(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Keith Pierno <a class="moz-txt-link-rfc2396E" href="mailto:kpierno(at)lulu(dot)com"><kpierno(at)lulu(dot)com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for the prompt response. If such a file is needed for recovery
it was never created by postgres. The current archiving process creates
uses rsync to archive the WAL files to a shared archive area. In the
past and on my other cluster we do not see .history files on the
primary server and have been able to recover without them.
</pre>
</blockquote>
<pre wrap=""><!---->
The .history file would have been created on the slave at the time it
became new master (and started its own timeline).
regards, tom lane
</pre>
</blockquote>
<br>
</body>
</html>