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
>
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 |