Re: On markers of changed data

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.

In response to

Browse pgsql-hackers by date

  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