Re: PITR Archival

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: PITR Archival
Date: 2004-06-15 16:56:05
Message-ID: 1087318564.12015.44.camel@stromboli
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Andreas Pflug 2004-06-15 17:10:46 Re: stderr & win32 admin check
Previous Message Simon Riggs 2004-06-15 16:34:47 Re: Fix for erroneous warning on Shutdown