Re: Enabling Checksums

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: Enabling Checksums
Дата
Msg-id 50A0B6E7.6060502@bluegap.ch
обсуждение исходный текст
Ответ на Re: Enabling Checksums  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Enabling Checksums  (Craig Ringer <craig@2ndQuadrant.com>)
Re: Enabling Checksums  (Jeff Davis <pgsql@j-davis.com>)
Re: Enabling Checksums  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
Jeff,

On 11/10/2012 12:08 AM, Jeff Davis wrote:
> The bit indicating that a checksum is present may be lost due to
> corruption.

Hm.. I see.

Sorry if that has been discussed before, but can't we do without that
bit at all? It adds a checksum switch to each page, where we just agreed
we don't event want a per-database switch.

Can we simply write a progress indicator to pg_control or someplace
saying that all pages up to X of relation Y are supposed to have valid
checksums?

That would mean having to re-calculate the checksums on pages that got
dirtied before VACUUM came along to migrate them to having a checksum,
but that seems acceptable. VACUUM could even detect that case and
wouldn't have to re-write it with the same contents.

I realize this doesn't support Jesper's use case of wanting to have the
checksums only for newly dirtied pages. However, I'd argue that
prolonging the migration to spread the load would allow even big shops
to go through this without much of an impact on performance.

Regards

Markus Wanner



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Inadequate thought about buffer locking during hot standby replay
Следующее
От: Markus Wanner
Дата:
Сообщение: Re: Enabling Checksums