From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Subject: | Re: Speed up pg_checksums in cases where checksum already set |
Date: | 2021-06-02 05:05:44 |
Message-ID: | YLcRqGIwMSmVvB+h@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-06-02 05:20:10 | Re: Two patches to speed up pg_rewind. |
Previous Message | Michael Paquier | 2021-06-02 04:29:26 | Re: Fixup some appendStringInfo and appendPQExpBuffer calls |