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 CAKAnmmK0RK-3Q=XibXPxCziA1PpK7cmz1aKvGA=TRhEPzUikpA@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
Thanks for the quick replies, everyone.

On Wed, May 26, 2021 at 10:17 PM Michael Paquier <michael@paquier.xyz> wrote:

-    if (do_sync)
+    if (do_sync && total_files_modified)
Here, I am on the edge.  It could be an advantage to force a flush of
the data folder anyway, no?

I was originally on the fence about including this as well, but it seems like since the database is shut down and already in a consistent state, there seems no advantage to syncing if we have not made any changes. Things are no better or worse than when we arrived. However, the real-world use case of running pg_checksums --enable and getting no changed blocks is probably fairly rare, so if there is a strong objection, I'm happy reverting to just (do_sync). (I'm not sure how cheap a sync is, I assume it's low impact as the database is shut down, I guess it becomes a "might as well while we are here"?)

On Wed, May 26, 2021 at 10:29 PM Justin Pryzby <pryzby@telsasoft.com> 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.
...
Does your patch complicate things for the "stop all the clusters before
switching them all" case?

I cannot imagine how it would, but, like Michael, I'm not really understanding the reasoning here. We only run when safely shutdown, so no WAL or dirty buffers need concern us :). Of course, once the postmaster is up and running, fiddling with checksums becomes vastly more complicated, as evidenced by that thread. I'm happy sticking to and speeding up the offline version for now.

Cheers,
Greg

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Reducing the range of OIDs consumed by genbki.pl