Re: [HACKERS] Checksums by default?

Поиск
Список
Период
Сортировка
От Torsten Zuehlsdorff
Тема Re: [HACKERS] Checksums by default?
Дата
Msg-id 3957c2ad-3d10-8b25-b6e2-6813c27b5386@toco-domains.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Checksums by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 21.01.2017 19:35, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> Sure, it might be easy, but we don't have it.  Personally I think
>> checksums just aren't even ready for prime time. If we had:
>> - ability to switch on/off at runtime (early patches for that have IIRC
>>   been posted)
>> - *builtin* tooling to check checksums for everything
>> - *builtin* tooling to compute checksums after changing setting
>> - configurable background sweeps for checksums
>
> Yeah, and there's a bunch of usability tooling that we don't have,
> centered around "what do you do after you get a checksum error?".
> AFAIK there's no way to check or clear such an error; but without
> such tools, I'm afraid that checksums are as much of a foot-gun
> as a benefit.

I wanted to raise the same issue. A "something is broken" flag is fine 
to avoid more things get broken. But if you can't repair them, its not 
very useful.

Since i'm a heavy user of ZFS: there are checksums and if you enable 
shadow-copies or using a raid, checksums are helpful, since the allow to 
recover from the problems.

I personally would prefer to enable checksums manually and than get the 
possibility to repair damages. Manually because this would at least 
double the needed space.

Greetings,
Torsten



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Protect syscache from bloating with negative cacheentries
Следующее
От: Torsten Zuehlsdorff
Дата:
Сообщение: Re: [HACKERS] Checksums by default?