| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Ashwin Agrawal <aagrawal(at)pivotal(dot)io> |
| Cc: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: block-level incremental backup |
| Date: | 2019-04-10 17:08:55 |
| Message-ID: | CA+TgmobS4A87wq6OMFGkDSvd-gM8ZNOOhAxPkzdPRWCdWOQRiA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 10, 2019 at 12:56 PM Ashwin Agrawal <aagrawal(at)pivotal(dot)io> wrote:
> Not to fork the conversation from incremental backups, but similar approach is what we have been thinking for pg_rewind. Currently, pg_rewind requires all the WAL logs to be present on source side from point of divergence to rewind. Instead just parse the wal and keep the changed blocks around on sourece. Then don't need to retain the WAL but can still rewind using the changed block map. So, rewind becomes much similar to incremental backup proposed here after performing rewind activity using target side WAL only.
Interesting. So if we build a system like this for incremental
backup, or for pg_rewind, the other one can use the same
infrastructure. That sound excellent. I'll start a new thread to
talk about that, and hopefully you and Heikki and others will chime in
with thoughts.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2019-04-10 17:14:17 | Re: Status of the table access method work |
| Previous Message | Robert Haas | 2019-04-10 17:03:26 | Re: block-level incremental backup |