| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | desmodemone <desmodemone(at)gmail(dot)com> |
| Cc: | 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-07-31 20:13:19 |
| Message-ID: | CAGTBQpb5cer1=yn1HZF9-FeZBEPtLMarcFVPWdwmgVuBUD=nXg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 31, 2014 at 5:26 AM, desmodemone <desmodemone(at)gmail(dot)com> wrote:
> b) yes the backends need to update the map, but it's in memory, and as I
> show, could be very small if we you chunk of blocks.If we not compress the
> map, I not think could be a bottleneck.
If it's in memory, it's not crash-safe. For something aimed at
backups, I think crash safety is a requirement. So it's at least one
extra I/O per commit, maybe less if many can be coalesced at
checkpoints, but I wouldn't count on it too much, because worst cases
are easy to come by (sparse enough updates).
I think this could be pegged on WAL replay / checkpoint stuff alone,
so it would be very asynchronous, but not free.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2014-07-31 21:27:00 | Re: delta relations in AFTER triggers |
| Previous Message | Peter Geoghegan | 2014-07-31 20:12:29 | Re: B-Tree support function number 3 (strxfrm() optimization) |