Re: Speed up pg_checksums in cases where checksum already set

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Speed up pg_checksums in cases where checksum already set
Дата
Msg-id YK8dOPzITUFj/C2I@paquier.xyz
обсуждение исходный текст
Ответ на Re: Speed up pg_checksums in cases where checksum already set  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Wed, May 26, 2021 at 09:29:43PM -0500, Justin Pryzby wrote:
> In one of the checksum patches, there was an understanding that the pages
> should be written even if the checksum is correct, to handle replicas.
>
> From the v19 patch:
> https://www.postgresql.org/message-id/F7AFCFCD-8F77-4546-8D42-C7F675A4B680%40yesql.se
> +                * Mark the buffer as dirty and force a full page write.  We have to
> +                * re-write the page to WAL even if the checksum hasn't changed,
> +                * because if there is a replica it might have a slightly different
> +                * version of the page with an invalid checksum, caused by unlogged
> +                * changes (e.g. hintbits) on the master happening while checksums
> +                * were off. This can happen if there was a valid checksum on the page
> +                * at one point in the past, so only when checksums are first on, then
> +                * off, and then turned on again.

I am not really following the line of argument here.  pg_checksums
relies on the fact that the cluster has been safely shut down before
running.  So, if this comes to standbys, they would have reached a
consistent point, and the shutdown makes sure that all pages are
flushed.
--
Michael

Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Decoding speculative insert with toast leaks memory