> 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). 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.
Actually it might even be possible to do the WAL redo based on
an inconsistent backup (e.g. done with tar/cpio), but that probably needs
more thought and testing than above. At the least, the restore would need to
generate a valid pg_control before starting redo.
pgsql-hackers by date
|Next:||From: Klaus Reger||Date: 2001-07-04 09:06:38|
|Subject: Get table/field-identifiers in uppercase|
|Previous:||From: Tom Lane||Date: 2001-07-04 03:29:36|
|Subject: Re: Buffer access rules, and a probable bug |