From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: On markers of changed data |
Date: | 2017-10-15 10:11:24 |
Message-ID: | A7F58A00-0EC2-4F5A-9B4A-CDFE92FFA62F@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello!
> 9 окт. 2017 г., в 10:23, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> написал(а):
>
> Thanks, Stephen, this actually pointed what to look for
> VM is WAL-logged [0]
> FSM is not [1]
>
> [0] https://github.com/postgres/postgres/blob/113b0045e20d40f726a0a30e33214455e4f1385e/src/backend/access/heap/visibilitymap.c#L315
> [1] https://github.com/postgres/postgres/blob/1d25779284fe1ba08ecd57e647292a9deb241376/src/backend/storage/freespace/freespace.c#L593
After tests of binary equivalence before and after backup I've come to conclusion, that Visibility Map cannot be backuped incrementally: it's bits are unset without page LSN bump. This can lead to wrong results of Index Only Scans executed on freshly restored backups.
In my implementation of incremental backup in WAL-G I will disable any FSM, VM and XACT\CLOG incrementation.
Posting this for the record, so that if someone goes this way info will be available. Thank you for your attention.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-10-15 10:48:34 | Re: oversight in EphemeralNamedRelation support |
Previous Message | legrand legrand | 2017-10-15 10:07:53 | Re: SAP Application deployment on PostgreSQL |