Re: Read-ahead and parallelism in redo recovery

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Read-ahead and parallelism in redo recovery
Дата
Msg-id 47CBD811.4090902@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Read-ahead and parallelism in redo recovery  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: Read-ahead and parallelism in redo recovery  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables