RE: AW: Backup, restore & pg_dump

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

> > > No, but rollforward is currently the main feature, no ?
> > 
> > I'm going to rollback changes on abort in 7.1. Seems I've
> > mentioned both redo and UNDO (without compensation records)
> > AM methods many times.
> 
> I don't think that I misunderstood anything here. If the commit 
> record is in the tx log this tx will have to be rolled forward, and
> not aborted. Of course open tx's on abort will be rolled back.
> But this roll forward for committed tx could be a starting point, no?

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?

> > > Does it make sense to ship WAL without using it's currently 
> > > main feature ?
> > 
> > Sorry, but it's not always possible to have all at once.
> 
> Sorry, my main point was not to argument against WAL in 7.1,
> but to state, that backup/restore would be very important.

Yes but I'm not able to do this work. And note that with WAL in
7.1 we could add backup/restore in any version > 7.1 (eg 7.1.1).

> > (BTW, replication server prototype announced by Pgsql, Inc
> > could be used for incremental backup)
> 
> Yes, that could be a good starting point for rollforward if it is 
> based on WAL.

It's not.

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

Vadim