Re: Speed up pg_checksums in cases where checksum already set

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

In response to

Responses

Browse pgsql-hackers by date

  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