I have added the following TODO:
* Speed WAL recovery by allowing more than one page to be prefetched
This involves having a 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 <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
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
