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

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