Re: PITR Archival - Mailing list pgsql-patches

From Simon Riggs
Subject Re: PITR Archival
Date
Msg-id 1087318564.12015.44.camel@stromboli
Whole thread Raw
In response to PITR Archival  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: PITR Archival  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
On Tue, 2004-06-15 at 16:34, Simon Riggs wrote:
> I enclose a working set of context diff patches and new files to make
> PITR archiving work, as of cvstip (NOW).
>
> You'll see the new options in the postgresql.conf...though you may wish
> to use archive_debug = true as well, when testing.
>
> There is one bug: shutdown doesn't work quite right. I haven't fixed
> this because I've spent too long trying to decipher how pgstat did a
> clean shutdown, discovering now that it didn't and that has now been
> patched...something similar is required for pgarch, but I'm out of time
> now...leaving time for discussion of this lot...
>

The patch creates a further child process of postmaster, the archiver.

Archiver code is similar, but not the same, as pgstat.c, and by analogy
lives in src/backend/postmaster/pgarch.c with a matching pgarch.h in
src/include (just as with pgstat.h)

At various points, 5 processes are involved, all of which are identified
clearly in the debugging messages...
- backend: sends signal to postmaster to say xlog is ready to archive
- postmaster: catches and resends to archiver
- archiver: then calls system(3) to invoke a user-defined archival task
- bgwriter: later cleans up archive_status at checkpoint time

Please note: you will need to initdb to make this work

Also note: archive_mode is not designed to be turned on/off frequently.
It is possible to confuse it if you turn it on, then restart with it
off, then turn it on again. That is likely to create a "hole" in the
archive history of xlogs and you will not be able to recover correctly.

You may also note that the design has changed substantially from many
earlier design postings...all of this is based on community input to
rationalise behaviour and to streamline code.

If you wish to test recovery, you should:
- do a full physical backup of DataDir, while postmaster is UP
- archive all xlogs

when disaster strikes
- restore backup of DataDir
- restore all archived xlogs to pg_xlog
- startup postmaster (and watch...)

Further work is still required to make it STOP recovering at a
predetermined point in time....

Best regards, Simon Riggs


pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Fix for erroneous warning on Shutdown
Next
From: Andreas Pflug
Date:
Subject: Re: stderr & win32 admin check