| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Aidan Van Dyk" <aidan(at)highrise(dot)ca> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Decibel!" <decibel(at)decibel(dot)org>, "Florian Weimer" <fweimer(at)bfk(dot)de>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Read-ahead and parallelism in redo recovery |
| Date: | 2008-03-03 10:50:57 |
| Message-ID: | 47CBD811.4090902@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-03-03 12:13:56 | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables |
| Previous Message | Heikki Linnakangas | 2008-03-03 08:34:50 | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables |