Re: Attempt to re-archive existing WAL logs after restoring from backup - Mailing list pgsql-admin

From Jon Colverson
Subject Re: Attempt to re-archive existing WAL logs after restoring from backup
Date
Msg-id 465E55F2.2020103@vcxz.co.uk
Whole thread Raw
In response to Attempt to re-archive existing WAL logs after restoring from backup  (Jon Colverson <pgsql@vcxz.co.uk>)
Responses Re: Attempt to re-archive existing WAL logs after restoring from backup  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
Jon Colverson wrote:
> I've been testing my DB backup and restore procedure and I've run into
> something I can't figure out. After recovering from a PITR backup, when
> I do another pg_start_backup PostgreSQL attempts to re-archive the last
> log again, which fails because it already exists in the archive.

Hello again. I've been investigating this some more and I've got some
more details to add:

In xlog.c, exitArchiveRecovery() moves the last restored log file into
XLOGDIR.

Later (when shutting down the cluster, for instance),
XLogArchiveCheckDone() is called on the log file. This function looks
for a ".done" or ".ready" file and finds neither, so it calls
XLogArchiveNotify() to create the ".ready" file. This causes the
archiver to come along later and attempt to archive the log and this
fails because the log already exists in the archive (that's where it
came from).

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?

--
Jon

pgsql-admin by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: High Avaliable in the PostgreSQL.
Next
From: adey
Date:
Subject: Re: High Avaliable in the PostgreSQL.