I have added the following TODO:* Speed WAL recovery by allowing more than one page to be prefetched This involves
havinga separate process that can be told which pages the recovery process will need in the near future.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php
---------------------------------------------------------------------------
Heikki Linnakangas wrote:
> Aidan Van Dyk wrote:
> > How difficult is it to parse the WAL logs with enough knowledge to know
> > what heap page (file/offset) a wal record contains (I haven't looked
> > into any wal code)?
>
> Unfortunately there's no common format for that. All the heap-related
> WAL records, insert, update and delete, have a
> RelFileNode+ItemPointerData at the beginning of the WAL payload, but
> update records have another ItemPointerData for the tid of the new tuple
> in addition to that. And all indexam WAL records use a format of their own.
>
> It would be nice to refactor that so that there was a common format to
> store the file+block number touched by WAL record. Like we have for full
> page images. That would useful for all kinds of external tools to parse
> WAL files, like the read-ahead restore_command you envisioned.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your Subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-hackers
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
