From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Tracking of page changes for backup purposes. PTRACK [POC] |
Date: | 2017-12-18 12:36:34 |
Message-ID: | C46F99CD-D22E-49DB-83B2-395413E7F80B@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)lubennikova(at)postgrespro(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-12-18 12:59:31 | Re: genomic locus |
Previous Message | Aleksander Alekseev | 2017-12-18 12:34:35 | Re: File name as application name in regression tests and elsewhere |