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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Colin Strickland | 2001-07-04 12:00:27 | Re: [OT] Any major users of postgresql? |
Previous Message | Andrew McMillan | 2001-07-04 11:27:31 | Re: [OT] Any major users of postgresql? |