Re: Read-ahead and parallelism in redo recovery - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Read-ahead and parallelism in redo recovery
Date
Msg-id 47CBD811.4090902@enterprisedb.com
Whole thread Raw
In response to Re: Read-ahead and parallelism in redo recovery  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Read-ahead and parallelism in redo recovery
List 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


pgsql-hackers by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Next
From: Alvaro Herrera
Date:
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables