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

Re: Attempt to re-archive existing WAL logs after restoring from backup

From: Jon Colverson <pgsql(at)vcxz(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Attempt to re-archive existing WAL logs after restoring from backup
Date: 2007-05-31 15:09:53
Message-ID: 465EE541.3020501@vcxz.co.uk (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackers
Thanks for your reply.

Tom Lane wrote:
> Jon Colverson <pgsql(at)vcxz(dot)co(dot)uk> writes:
>> So, I think the problem is that exitArchiveRecovery() should be marking 
>> the restored log file as ".done" (or perhaps not bothering to restore 
>> the log file at all?).
> 
>> This looks like a bug to me. Any thoughts?
> 
> I don't think that will fix it.  The problem is that after recovery
> we try to use the rest of the last WAL segment for fresh WAL data, and
> therefore need to modify the segment, and therefore need to (re) archive
> it.  We can't fix that by doing a forced switch to a new segment, because
> that still requires writing a switch record at the right place in the
> last segment.  There's really no way to make this work without
> abandoning the principle that the archive process should never overwrite
> files.  (Which is certainly not a logically *necessary* thing, but it
> seems like a mighty good idea from a safety perspective.)

I'm not sure this is quite right. Any log in the archive is, by 
definition, a complete log that will have the switch record already 
(because it will only have been marked for archiving after being 
completed). Hence I don't really understand why the last one is being 
copied back to pg_xlog after being used in the recovery. The long 
comment in exitArchiveRecovery() explains that this is to replace any 
existing version of the file in pg_xlog, but I think it would be just as 
valid to simply remove any existing version since it is definitely out 
of date (iff restoredFromArchive).

> I believe that this situation doesn't come up in ordinary scenarios
> because a WAL segment doesn't get archived until it's really filled.
> I take it you are using a backup procedure that undertakes to force the
> last partial segment into the archive after a postmaster shutdown.  I'd

No; nothing is touching the archive except for the archive_command being 
run by PostgreSQL.

-- 
Jon

In response to

Responses

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2007-05-31 15:36:53
Subject: Re: timestamp datatyp problem
Previous:From: Mathias PalmDate: 2007-05-31 15:04:10
Subject: timestamp datatyp problem

pgsql-admin by date

Next:From: Tom LaneDate: 2007-05-31 15:44:30
Subject: Re: Fwd: Out of Memory on Reindex
Previous:From: Chris HooverDate: 2007-05-31 15:07:32
Subject: Re: Fwd: Out of Memory on Reindex

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