> > > > 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.
It actually even contains the information needed to take an
inconsistent binary table image from any point in time to as far as you
have WAL records for. The only prerequisite is, that you apply
at least all those WAL records that where created during the time window
from start of reading the binary table image until end of reading
for backup.
If you want to restore a whole instance from an inconsistent physical dump,
you need to apply at least all WAL records from the time window from start of
whole physical dump to end of your whole physical dump. This would have the
advantage of not needing any synchronization with the backend for doing
the physical dump. (It doesen't even matter if you read inconsistent pages,
since those will be restored by "physical log" in WAL later.) If you start
the physical dump with pg_control, you might not need to reconstruct one for
rollforward later.
> > IIUC, it is meaningless in relation to a pg_dump image.
Yes, pg_dump produces a "logical snapshot". You cannot use a data content
dump for later rollforward.
Andreas