From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)heroku(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Checksums by default? |
Date: | 2017-02-03 23:44:30 |
Message-ID: | CA+TgmobHd+-yVJHofSWg=g+=A3EiCN2wsAiEyj7dj1hhevNq9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 30, 2017 at 12:29 PM, David Steele <david(at)pgmasters(dot)net> wrote:
> The solution was to simply ignore the checksums of any pages with an LSN
>>= the LSN returned by pg_start_backup(). This means that hot blocks
> may never be checked during backup, but if they are active then any
> problems should be caught directly by PostgreSQL.
I feel like this doesn't fix the problem. Suppose the backup process
reads part of a block that hasn't been modified in a while, and then
PostgreSQL writes the block, and then the backup process reads the
rest of the block. The LSN test will not prevent the checksum from
being verified, but the checksum will fail to match.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2017-02-03 23:46:43 | Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather) |
Previous Message | Andres Freund | 2017-02-03 23:31:25 | Re: Checksums by default? |