Re: Speed up pg_checksums in cases where checksum already set
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Justin Pryzby <pryzby@telsasoft.com>
Date: 2021-06-02T05:05:44Z
Lists: 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
Commits
-
Optimize pg_checksums --enable where checksum is already set
- 4c9f50d11646 15.0 landed