AW: AW: Backup, restore & pg_dump

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: AW: Backup, restore & pg_dump
Date: 2000-10-19 09:25:05
Message-ID: 11C1E6749A55D411A9670001FA6879633680B9@sdexcsrv1.f000.d0188.sd.spardat.at
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?

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-10-19 09:38:47 Re: INHERITS doesn't offer enough functionality
Previous Message Hiroshi Inoue 2000-10-19 09:24:56 Re: time stops within transaction