> > > As for replaying logs against a restored snapshot dump... AIUI, a
> > > dump records tuples by OID, but the WAL refers to TIDs. Therefore,
> > > the WAL won't work as a re-do log to recover your transactions
> > > because the TIDs of the restored tables are all different.
> > True for current way of backing up - ie saving data in "external"
> > (sql) format. But there is another way - saving data files in their
> > natural (binary) format. WAL records may be applyed to
> > such dump, right?
> But (AIUI) you can only safely/usefully copy those files when the
> database is shut down.
No. You can read/save datafiles at any time. But block reads must be
"atomic" - no one should be able to change any part of a block while
we read it. Cp & tar are probably not suitable for this, but internal
BACKUP command could do this.
Restoring from such backup will like recovering after pg_ctl -m i stop: all
data blocks are consistent and WAL records may be applyed to them.
> Many people hope to run PostgreSQL 24x7x365. With vacuuming, you
> might just as well shut down afterward; but when that goes away
> (in 7.2?), when will you get the chance to take your backups?
Ability to shutdown 7.2 will be preserved -:))
But it's not required for backup.
> > > To get replaying we need an "update log", something that might be
> > > in 7.2 if somebody does a lot of work.
> > What did you mean by "update log"?
> > Are you sure that WAL is not "update log" ? -:)
> No, I'm not sure. I think it's possible that a new backup utility
> could be written to make a hot backup which could be restored and
> then replayed using the current WAL format. It might be easier to
> add another log which could be replayed against the existing form
> of backups. That last is what I called the "update log".
Consistent read of data blocks is easier to implement, sure.
> The point is, WAL now does one job superbly: maintain a consistent
> on-disk database image. Asking it to do something else, such as
> supporting hot BAR, could interfere with it doing its main job.
> Of course, only the person who implements hot BAR can say.
There will be no interference because of BAR will not ask WAL to do
anything else it does right now - redo-ing changes.
In response to
pgsql-hackers by date
|Next:||From: pejac||Date: 2000-12-01 16:17:36|
|Subject: Bitmap index|
|Previous:||From: Don Baccus||Date: 2000-12-01 14:57:45|
|Subject: Re: [HACKERS] Re: PHPBuilder article -- Postgres