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 | YLcRqGIwMSmVvB+h@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Speed up pg_checksums in cases where checksum already set (Greg Sabino Mullane <htamfids@gmail.com>) |
Ответы |
Re: Speed up pg_checksums in cases where checksum already set
|
Список | pgsql-hackers |
On Thu, May 27, 2021 at 10:29:14AM -0400, Greg Sabino Mullane wrote: > 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"?) I understand that this should be rare, but I don't want to take any bets either. With this patch, we could finish with cases where some pages are still in the OS cache but don't get flushed because a previous cancellation let the cluster in a state where all the page checksums have been written out but a portion of the files were not synced. A follow-up run of pg_checksums would see that all the pages are correct, but would think that no sync is required, incorrectly. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: