Re: PITR, checkpoint, and local relations

From: Richard Tucker <richt(at)multera(dot)com>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PITR, checkpoint, and local relations
Date: 2002-08-02 22:40:27
Message-ID: EKEKLEKKLDAEEKDBDMMAKEGFCDAA.richt@multera.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Mikheev, Vadim
> Sent: Friday, August 02, 2002 6:16 PM
> To: 'richt(at)multera(dot)com'; J. R. Nield
> Cc: Tom Lane; Bruce Momjian; PostgreSQL Hacker
> Subject: Re: [HACKERS] PITR, checkpoint, and local relations
>
>
> > > > As long as whole block is saved in log on first after
> > > > checkpoint (you made before backup) change to block.
> > >
> > I thought half the point of PITR was to be able to
> > turn off pre-image logging so you can trade potential
> > recovery time for speed without fear of data-loss.
> > Didn't we have this discussion before?
>
> > Suppose you can turn off/on PostgreSQL's atomic write on
> > the fly. Which means turning on or off whether XLoginsert
> > writes a copy of the block into the log file upon first
> > modification after a checkpoint.
> > So ALTER SYSTEM BEGIN BACKUP would turn on atomic write
> > and then checkpoint the database.
> > So while the OS copy of the data files is going on the
> > atomic write would be enabled. So any read of a partial
> > write would be fixed up by the usual crash recovery mechanism.
>
> Yes, simple way to satisfy everyone.

By the way I could supply a patch which turns off the atomic write feature.
It is disabled via a configuration parameter. If the flag enabling /
disabling the feature were added to shared memory, XLogCtl struture, then it
could be toggled at runtime.

So I think what will work then is pg_copy (hot backup) would:
1) Issue an ALTER SYSTEM BEGIN BACKUP command which turns on atomic write,
checkpoints the database and disables further checkpoints (so wal files
won't be reused) until the backup is complete.
2) Change ALTER SYSTEM BACKUP DATABASE TO <directory> read the database
directory to find which files it should backup rather than pg_class and for
each file just use system(cp...) to copy it to the backup directory.
3) ALTER SYSTEM FINISH BACKUP does at it does now and backs up the pg_xlog
directory and renables database checkpointing.

Does this sound right?

BTW I will be on vacation until next Wednesday.

>
> Vadim
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-08-02 22:42:45 Re: Build errors with current CVS
Previous Message J. R. Nield 2002-08-02 22:24:07 Re: PITR, checkpoint, and local relations