Re: Speed up pg_checksums in cases where checksum already set

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: Speed up pg_checksums in cases where checksum already set
Дата
Msg-id CAKAnmmKhxLgEUFHEOrw06W+=NAVvZvR6-L+qybneZj8bjxmg=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Speed up pg_checksums in cases where checksum already set  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Speed up pg_checksums in cases where checksum already set  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Дерево обсуждения
On Fri, Jun 18, 2021 at 1:57 AM Michael Paquier <michael@paquier.xyz> wrote:
This doc addition is a bit confusing, as it could mean that each file
has just one single checksum.  We could be more precise, say:
"When enabling checksums, each relation file block with a changed
checksum is rewritten in place."

Agreed, I like that wording. New patch attached.
 
Should we also mention that the sync happens even if no blocks are
rewritten based on the reasoning of upthread (aka we'd better do the
final flush as an interrupted pg_checksums may let a portion of the
files as not flushed)?

I don't know that we need to bother: the default is already to sync and one has to go out of one's way using the -N argument to NOT sync, so I think it's a pretty safe assumption to everyone (except those who read my first version of my patch!) that syncing always happens.

Cheers,
Greg
 
Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pgbench logging broken by time logic changes
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Optionally automatically disable logical replication subscriptions on error