Skip site navigation (1) Skip section navigation (2)

Re: restoring wal archive and pg_xlog dir

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Jeff Frost <jeff(at)frostconsultingllc(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: restoring wal archive and pg_xlog dir
Date: 2005-06-23 21:40:44
Message-ID: 1119562844.3645.549.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Thu, 2005-06-23 at 10:55 -0700, Jeff Frost wrote:
> When reading the docs on recovery.conf, I noticed this:
>   WAL segments that cannot be found in the archive will be sought in pg_xlog/; 
> this allows use of recent un-archived segments. However segments that are 
> available from the archive will be used in preference to files in pg_xlog/. The 
> system will not overwrite the existing contents of pg_xlog/ when retrieving 
> archived files.
> If the system will use the files in the archive in preference to the ones in 
> pg_xlog, how can this actually happen if it will not overwrite the contents of 
> pg_xlog?

That was the bit I thought of. The files are streamed in one by one using a temp filename, so you never run out of space no matter how big the archive of transaction logs. Thats an important feature if a base backup goes bad and you have to go back to n-1 base backup.

> I also noticed that if there is not at least one wal archive available in
> the archive or the pg_xlog dir, the restore errors out and exits.  So the
> base backup is really not complete without at least one wal archive
> following it.  Is this by design?

That was the bit I didn't. Fix partially implemented and I am to submit
for 8.1, godspeed my typing fingers. There's a simple workaround if you
have a low transaction rate system: load up enough data to trip into the
next xlog.

Best Regards, Simon Riggs

In response to


pgsql-admin by date

Next:From: Vladimir YevdokimovDate: 2005-06-23 21:48:19
Subject: Re: psql copy errors
Previous:From: Michael FuhrDate: 2005-06-23 20:17:16
Subject: Re: psql copy errors

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group