Re: Tracking of page changes for backup purposes. PTRACK [POC]
От | Andrey Borodin |
---|---|
Тема | Re: Tracking of page changes for backup purposes. PTRACK [POC] |
Дата | |
Msg-id | C46F99CD-D22E-49DB-83B2-395413E7F80B@yandex-team.ru обсуждение исходный текст |
Ответ на | Tracking of page changes for backup purposes. PTRACK [POC] (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: Tracking of page changes for backup purposes. PTRACK [POC]
|
Список | pgsql-hackers |
Hello! Thanks for sharing this work! I think this is important feature to make backups more efficient. > 18 дек. 2017 г., в 15:18, Anastasia Lubennikova <a.lubennikova@postgrespro.ru> написал(а): > > Patches for v 10.1 and v 9.6 are attached. > Since ptrack is basically just an API for use in backup tools, it is > impossible to test the patch independently. > Now it is integrated with our backup utility, called pg_probackup. You can > find it herehttps://github.com/postgrespro/pg_probackup I can add experimental support for WAL-G too. We have QA tools for delta backups too. > > Spoiler: Please consider this patch and README as a proof of concept. It > can be improved in some ways, but in its current state PTRACK is a > stable prototype, reviewed and tested well enough to find many > non-trivial corner cases and subtle problems. And any discussion of > change track algorithm must be aware of them. Feel free to share your > concerns and point out any shortcomings of the idea or the implementation. This version of the patch is quite big - basically it accompanies most of START_CRIT_SECTION() calls with PTRACK calls. I have two concerns about this: 1. Does this affect the performance of the database when PTRACK is not enabled? 2. What is the cost of having PTRACK enabled? Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: