Thread: AW: AW: Backup, restore & pg_dump

AW: AW: Backup, restore & pg_dump

From
Zeugswetter Andreas SB
Date:
> 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


Re: AW: AW: Backup, restore & pg_dump

From
Philip Warner
Date:
At 10:38 18/10/00 +0200, Zeugswetter Andreas SB wrote:
>
>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 ....)

You may be tying implementation too closely to function; so long as
succesive incremental backups are (a) incremental since the last higher
level backup, and (b) sufficient to restore the database when cobined with
other incremental backups, then ISTM that the method of deriving the backup
(from logs, or reading data pages) is irrelevant.

I too am used to incremental backups that actually read data pages, but if
the WAL has enough information to determine the pages, the why not use
it...but maybe I'm missing something.




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


RE: AW: AW: Backup, restore & pg_dump

From
"Mikheev, Vadim"
Date:
> Do we have the info when a page was last modified (in respect 
> to a WAL position, not wallclock time) on each page ? This is
> probably an info we will need.

How else one could know was a change applied to page or not?

Vadim