AW: AW: Backup, restore & pg_dump - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: Backup, restore & pg_dump
Date
Msg-id 11C1E6749A55D411A9670001FA6879633680B1@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List 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 :-)

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

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

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

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.

Andreas


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [BUGS] UPPER and LOWER dosen't work correctly on special caracters (umlauts)
Next
From: Karel Zak
Date:
Subject: Re: time stops within transaction