Re: [HACKERS] On markers of changed data

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: [HACKERS] On markers of changed data
Дата
Msg-id 666B4D85-561C-47CA-8AE5-F1E628AD1468@yandex-team.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] On markers of changed data  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Hi Michael!
9 окт. 2017 г., в 17:28, Michael Paquier <michael.paquier@gmail.com> написал(а):
VM is WAL-logged [0]
FSM is not [1]

If you are willing to go down this road, here are my takes on the matter:
- Any LSN map should be in a different file than FSM and VM. The VM
uses 2 bits per blocks now, and the FSM 8 bits. The FSM is wanted to
remain small, so trying to plug into it more data is not welcome. The
VM bits also are dedicated to purely visibility matters. We may not
want to use that for the VM.
- Those should not be logged, as we would end up with tracking down
WAL records for things that themselves track the effects of other
records.
I was asking about FSM and VM not because I wanted to place something there, but because I was looking for the way to backup FSM and VM efficiently. VM can be copied page-incrementally, FSM cannot.

But the design you are describing resembles PTRACK[0]: fork for page changes tracking, not WAL-logged, but crash safe due to recovery from others WALs.

Best regards, Andrey Borodin.


[0] https://gist.github.com/stalkerg/ab833d94e2f64df241f1835651e06e4b

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] Pluggable storage
Следующее
От: Tom Lane
Дата:
Сообщение: [HACKERS] Unnecessary complexity around CurrentResourceOwner changes?