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

Thu, 19 Oct 2000 11:25:05 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: AW: Backup, restore & pg_dump
> 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).

How else to know from where in log to start redo and how far go back
for undo ?

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

And I've stated this as separate feature.

Vadim



Thu, 19 Oct 2000 13:02:45 -0700
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: AW: Backup, restore & pg_dump