From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Louis Fridkis <Louis(dot)Fridkis(at)fox(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pitr errors |
Date: | 2009-09-29 22:59:32 |
Message-ID: | alpine.GSO.2.01.0909291851460.18158@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 29 Sep 2009, Louis Fridkis wrote:
> When I check the WAL file directories I find that all is in order. The file
> 00000004.history does not exist, but it is not supposed to exist. The file
> 00000003000000EF000000A6 is not in the backup archive (archive_log) because
> it had not been moved there yet at the time I did the pitr.
If you look at the current docs, it addresses all this. Your message
suggests you might be looking at the docs from an earlier version but I
wasn't sure which, this might not have been as clear then.
http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html
"It is important that the [restore] command return nonzero exit status on
failure. The command will be asked for files that are not present in the
archive; it must return nonzero when so asked. This is not an error
condition. Not all of the requested files will be WAL segment files; you
should also expect requests for files with a suffix of .backup or
.history...Normally, recovery will proceed through all available WAL
segments, thereby restoring the database to the current point in time (or
as close as we can get given the available WAL segments). So a normal
recovery will end with a "file not found" message, the exact text of the
error message depending upon your choice of restore_command. You may also
see an error message at the start of recovery for a file named something
like 00000001.history. This is also normal and does not indicate a problem
in simple recovery situations. See Section 24.3.4 for discussion."
Are you using pg_standby for your restore_command? If not, you probably
should be. Not sure if all of the error messages you showed would go away
if you switched to it, but the specific "cp" errors you showed suggest
you're using the simple restore_command example from the manual there,
which is really not a production quality solution there.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-09-29 23:03:00 | Re: Performance evaluation of PostgreSQL's historic releases |
Previous Message | Sam Mason | 2009-09-29 22:57:31 | Re: bulk inserts |