Thanks for your reply.
Tom Lane wrote:
> Jon Colverson <pgsql@vcxz.co.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