From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(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-25 22:40:40 |
Message-ID: | CAGTBQpai13dnU6Od7o3fkJSPH2hMREf83MtGBSdc5WirSxzr4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 25, 2014 at 7:38 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 07/25/2014 11:49 AM, Claudio Freire wrote:
>>> I agree with much of that. However, I'd question whether we can
>>> > really seriously expect to rely on file modification times for
>>> > critical data-integrity operations. I wouldn't like it if somebody
>>> > ran ntpdate to fix the time while the base backup was running, and it
>>> > set the time backward, and the next differential backup consequently
>>> > omitted some blocks that had been modified during the base backup.
>> I was thinking the same. But that timestamp could be saved on the file
>> itself, or some other catalog, like a "trusted metadata" implemented
>> by pg itself, and it could be an LSN range instead of a timestamp
>> really.
>
> What about requiring checksums to be on instead, and checking the
> file-level checksums? Hmmm, wait, do we have file-level checksums? Or
> just page-level?
It would be very computationally expensive to have up-to-date
file-level checksums, so I highly doubt it.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-07-26 03:41:37 | Re: PDF builds broken again |
Previous Message | Josh Berkus | 2014-07-25 22:38:07 | Re: Proposal: Incremental Backup |