From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | AW: AW: Backup, restore & pg_dump |
Date: | 2000-10-19 09:25:05 |
Message-ID: | 11C1E6749A55D411A9670001FA6879633680B9@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > BTW, avoiding writes is base WAL feature, ie - it'll be
> > > implemented in 7.1.
> >
> > Wow, great, I thought first step was only to avoid sync :-)
>
> ? If syncs are not required then why to do write call?
Yes, writes are only necessary when "too many dirty pages"
are in the buffer pool. Those writes can be done by a page flusher
on demand or during checkpoint (don't know if we need checkpoint,
but you referred to doing checkpoints).
> Currently records inserted by aborted transactions remain in db
> untill vacuum. I try to rollback changes - ie *delete* inserted
> tuples on abort (though could do not do this), - isn't there
> some difference now?
this has two sides: less space wastage, but slower rollback.
What you state is a separate issue, and is not part of the
startup rollforward for committed tx'ns. It is part of the rollback
of aborted tx'ns.
> > We should not call this tx log business "Incremental backup"
> > an incremental backup scans all pages, and backs
> > them up if they changed in respect to the last higher level backup.
> > (full backup, level 1 backup, level 2 backup ....)
> > Oracle only uses this chargon, since they don't have such a
> > backup, and want to fool their customer's managers.
> > All other DB companies make correct use of the wording
> > "incremental backup" in the above sense.
>
> Scanning *all* pages?! Not the best approach imho.
> Or did you meant scanning log to get last *committed"
> changes to all pages - ie some kind of log compression?
You could call an incremental backup some kind of log compression, yes,
but it is usually done by reading base data pages (an optimization would be to
skip page ranges that are known to not have changed, but how do you know)
In the backup I have in mind there are 3 things:
1. full backup
2. tx log backup
3. incremental backup with multiple levels
Point 3 is something to keep in mind, but do later.
On restore you do
restore full backup (level 0)
restore incremental backup level 1 (pages that changed after level 0)
restore incremental backup level 2 (pages that changed after level 1)
restore tx logs that were written after level 2
The incremental backups are especially useful in an overwrite smgr,
where you can get a lot of tx log that only changes a few pages.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-10-19 09:38:47 | Re: INHERITS doesn't offer enough functionality |
Previous Message | Hiroshi Inoue | 2000-10-19 09:24:56 | Re: time stops within transaction |