From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Incremental Backup |
Date: | 2014-07-31 13:09:34 |
Message-ID: | 20140731130934.GE1040@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 31, 2014 at 11:30:52AM +0530, Amit Kapila wrote:
> On Wed, Jul 30, 2014 at 11:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > IMV, the way to eventually make this efficient is to have a background
> > process that reads the WAL and figures out which data blocks have been
> > modified, and tracks that someplace.
>
> Nice idea, however I think to make this happen we need to ensure
> that WAL doesn't get deleted/overwritten before this process reads
> it (may be by using some existing param or mechanism) and
> wal_level has to be archive or more.
Well, you probably are going to have all the WAL files available because
you have not taken an incremental backup yet, and therefore you would
have no PITR backup at all. Once the incremental backup is done, you
can delete the old WAL files if you don't need fine-grained restore
points.
Robert also suggested reading the block numbers from the WAL as they are
created and not needing them at incremental backup time.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-07-31 13:59:22 | pgsql: Move log_newpage and log_newpage_buffer to xlog.c. |
Previous Message | Robert Haas | 2014-07-31 12:57:41 | Re: Fixed redundant i18n strings in json |