Re: [HACKERS] On markers of changed data - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: [HACKERS] On markers of changed data
Date
Msg-id 666B4D85-561C-47CA-8AE5-F1E628AD1468@yandex-team.ru
Whole thread Raw
In response to Re: [HACKERS] On markers of changed data  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Pluggable storage
Next
From: Tom Lane
Date:
Subject: [HACKERS] Unnecessary complexity around CurrentResourceOwner changes?