| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it> |
| Cc: | desmodemone <desmodemone(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(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-08-04 18:30:21 |
| Message-ID: | CAGTBQpYD-7g+1562gRywGGR1DCaVTd5ni6wN7KeFrwTYphXnmg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
<gabriele(dot)bartolini(at)2ndquadrant(dot)it> wrote:
> I really like the proposal of working on a block level incremental
> backup feature and the idea of considering LSN. However, I'd suggest
> to see block level as a second step and a goal to keep in mind while
> working on the first step. I believe that file-level incremental
> backup will bring a lot of benefits to our community and users anyway.
Thing is, I don't see how the LSN method is that much harder than an
on-disk bitmap. In-memory bitmap IMO is just a recipe for disaster.
Keeping a last-updated-LSN for each segment (or group of blocks) is
just as easy as keeping a bitmap, and far more flexible and robust.
The complexity and cost of safely keeping the map up-to-date is what's
in question here, but as was pointed before, there's no really safe
alternative. Nor modification times nor checksums (nor in-memory
bitmaps IMV) are really safe enough for backups, so you really want to
use something like the LSN. It's extra work, but opens up a world of
possibilities.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2014-08-04 20:43:41 | Re: KNN-GiST with recheck |
| Previous Message | Alvaro Herrera | 2014-08-04 16:02:44 | Re: SKIP LOCKED DATA (work in progress) |