| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Aw: Re: pg_dump include/exclude data, was: verify checksums / CREATE DATABASE |
| Date: | 2019-06-11 23:54:38 |
| Message-ID: | 91e6acfa-3b6f-ed53-26b6-c3d6aa72c440@aklaver.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 6/11/19 11:15 AM, Karsten Hilbert wrote:
>>> The problem I hope to protect against with this approach: the
>>> CREATE DATABASE might untaint corrupted data from a bad disk
>>> block into a good disk block virtue of doing a file level
>>> copy.
>>>
>>> I hope my reasoning isn't going astray.
>>
>> As I understand it checksums are done on the page level using a hash(for
>> details: https://doxygen.postgresql.org/checksum__impl_8h_source.html)
>> I am not sure how a page could get un-corrupted by virtue of a file copy.
>
> Ah, no, I did not explain myself well.
>
> Let's assume a corrupted, bad (but readable at the hardware
> level) disk block B. A filesystem level copy (as in CREATE
> DATABASE) would successfully read that disk block B and
> copy the corrupted content into a good disk block G elsewhere
> on the disk. Verifying the checksum of the page sitting on
> block B before doing the database cloning would
> reveal the corruption before it got cloned.
>
> Does that make sense ?
Yes.
>
> Karsten
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igal Sapir | 2019-06-12 00:58:35 | Re: Featured Big Name Users of Postgres |
| Previous Message | Chris Travers | 2019-06-11 21:11:09 | Re: Featured Big Name Users of Postgres |