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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jon Colverson <pgsql(at)vcxz(dot)co(dot)uk>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Attempt to re-archive existing WAL logs after restoring from backup
Date: 2007-05-31 14:01:53
Message-ID: 28998.1180620113@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackers
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 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
recommend not doing it that way --- instead, if you want a deterministic
time that the backup is good up to, don't stop the postmaster at all,
just apply pg_switch_xlog() and let the regular archiving process
archive the thereby-completed segment file.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-05-31 14:08:05
Subject: Re: New cast between inet/cidr and bytea
Previous:From: Werner EchezuriaDate: 2007-05-31 13:58:27
Subject: SQLF Optimization question

pgsql-admin by date

Next:From: Chris HooverDate: 2007-05-31 14:07:14
Subject: Re: Fwd: Out of Memory on Reindex
Previous:From: Kristo KaivDate: 2007-05-31 06:45:06
Subject: Re: High Avaliable in the PostgreSQL.

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