On Sat, 2007-06-02 at 01:07 +0100, Jon Colverson wrote:
> Simon Riggs wrote:
> > I've spent some time re-examining the code and I can't see a route for
> > the discussed problem to occur. All the main code paths do not exhibit
> > this problem in 8.2, so I'm not sure where to go from here.
> >
> > If you can help further, please give me a shout.
>
> Thanks a lot for looking into this.
>
> I've attached a self-contained minimal shell script which sets up a
> cluster and demonstrates the problem. I hope that will provide an
> unambiguous description. I'm running it on Ubuntu 7.04 (i386) and the
> script includes all the commands to build PostgreSQL from scratch, but
> obviously you can snip that stuff out and change the paths to suit your
> environment.
>
> The script ends with the server log showing the archiver attempting to
> re-archive the last log that was restored in the recovery procedure.
Jon,
Your script is correct and there is a problem, as you demonstrate. Thank
you for bringing this to the list.
You have followed the manual in full. In Step 6 of the recovery
procedure outlined here
http://developer.postgresql.org/pgdocs/postgres/continuous-archiving.html#BACKUP-PITR-RECOVERY
we say that if you have partially completed WAL logs these should be
copied back into pg_xlog. This is correct and if we do this we avoid the
error you have highlighted. In the case of a true disaster recovery, as
you have attempted to test, no files are available and so an attempt is
made to archive the last restored file. That attempt fails iff you have
done as the manual suggests and used an archive_command that prevents
duplicate file insertions.
I'll repost to pgsql-hackers to discuss solutions. Fixes are simple, but
require some discussion.
Initially I thought you'd fallen foul of another problem which is known
to exist, which is caused by immediately shutting down a server after
having taken a hot backup. This isn't a problem in real usage though is
a problem in a scripted test. I've already proposed solutions there and
will pick up that thread again also.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com