Skip site navigation (1) Skip section navigation (2)

Re: Re: Backup and Recovery

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Backup and Recovery
Date: 2001-07-04 11:46:20
Message-ID: 20010704044620.A23814@store.zembu.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jul 04, 2001 at 10:37:57AM +0200, Zeugswetter Andreas SB wrote:
> 
> > I imagine a daemon extracting redo log entries from WAL segments, 
> > asynchronously.  Mixing redo log entries into the WAL allows the WAL 
> > to be the only synchronous disk writer in the system, a Good Thing.
> 
> This comes up periodically now. WAL currently already has all the info
> that would be needed for redo (it actually has to). 

The WAL has the information needed to take a binary table image
from the checkpoint state to the last committed transaction.
IIUC, it is meaningless in relation to a pg_dump image.

> All that is missing is a program, that can take a consistent physical
> snapshot (as it was after a particular checkpoint) and would replay
> the WAL after a restore of such a snapshot. This replay after a
> consistent snapshot is probably as simple as making the WAL files
> available to the standard startup rollforward (redo) mechanism, that
> is already implemented.

How would you take a physical snapshot without interrupting database 
operation?  Is a physical/binary snapshot a desirable backup format?  
People seem to want to be able to restore from ASCII dumps.

Also, isn't the WAL format rather bulky to archive hours and hours of?
I would expect high-level transaction redo records to be much more compact;
mixed into the WAL, such records shouldn't make the WAL grow much faster.

Nathan Myers
ncm(at)zembu(dot)com

In response to

Responses

pgsql-hackers by date

Next:From: Colin StricklandDate: 2001-07-04 12:00:27
Subject: Re: [OT] Any major users of postgresql?
Previous:From: Andrew McMillanDate: 2001-07-04 11:27:31
Subject: Re: [OT] Any major users of postgresql?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group