Re: [RFC] Incremental backup v3: incremental PoC
От | Gabriele Bartolini |
---|---|
Тема | Re: [RFC] Incremental backup v3: incremental PoC |
Дата | |
Msg-id | CAHNtfO6MjN7p1nQYBntQxp-j_Wk1LhSXwJojGa5JVC99CG43vg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] Incremental backup v3: incremental PoC (Marco Nenciarini <marco.nenciarini@2ndquadrant.it>) |
Ответы |
Re: [RFC] Incremental backup v3: incremental PoC
|
Список | pgsql-hackers |
Hi Marco,
could you please send an updated version the patch against the current HEAD in order to facilitate reviewers?
Thanks,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia - Managing Director
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it
Gabriele Bartolini - 2ndQuadrant Italia - Managing Director
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it
2015-01-07 11:00 GMT+01:00 Marco Nenciarini <marco.nenciarini@2ndquadrant.it>:
Il 06/01/15 14:26, Robert Haas ha scritto:
> I suggest leaving this out altogether for the first version. I can
> think of three possible ways that we can determine which blocks need
> to be backed up. One, just read every block in the database and look
> at the LSN of each one. Two, maintain a cache of LSN information on a
> per-segment (or smaller) basis, as you suggest here. Three, scan the
> WAL generated since the incremental backup and summarize it into a
> list of blocks that need to be backed up. This last idea could either
> be done when the backup is requested, or it could be done as the WAL
> is generated and used to populate the LSN cache. In the long run, I
> think some variant of approach #3 is likely best, but in the short
> run, approach #1 (scan everything) is certainly easiest. While it
> doesn't optimize I/O, it still gives you the benefit of reducing the
> amount of data that needs to be transferred and stored, and that's not
> nothing. If we get that much working, we can improve things more
> later.
>
Hi,
The patch now uses the approach #1, but I've just sent a patch that uses
the #2 approach.
54AD016E.9020406@2ndquadrant.it
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it
В списке pgsql-hackers по дате отправления: