From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: AW: Backup, restore & pg_dump |
Date: | 2000-10-18 21:40:31 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018D6E@SECTORBASE1 |
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?
> > > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2000-10-18 21:42:57 | RE: AW: AW: Backup, restore & pg_dump |
Previous Message | Don Baccus | 2000-10-18 21:36:18 | Re: time stops within transaction |