Thanks for your reply.
Tom Lane wrote:
Jon Colverson <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
