Re: basebackup: do not verify checksums on pages written before enabling checksums

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: basebackup: do not verify checksums on pages written before enabling checksums
Date: 2026-08-17 09:03:31
Message-ID: D5DC72A4-0CA7-49ED-9B8B-530D087F9551@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 17 Aug 2026, at 05:07, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> On Sat, Aug 15, 2026 at 03:30:56PM +0100, Zsolt Parragi wrote:

>> There was really an issue there, I think we can solve that by
>> advancing minrecoverypoint.
>
> Yeah, that works too.

Agreed, and there is prior art for this solution.

> IIUC we advance minRecoveryPoint for every checksum state
> record. I wonder if we could do so only when necessary, means when verification
> change (inprogress-on->on and on->inprogress-off). That said that's a nit as
> advancing it for every transition is simpler and less error prone.

I think we should still to doing it for every transition in 19, and if someone
feels like optimizing it can be revisited for 20.

> If we want to check that minRecoveryPoint >= final on record, could the test use
> datachecksums-enable-checksums-delay to pause before that transition and establish
> the restartpoint there?

I tried that in the attached 0002. The risk I see is that it may become flaky
if we don't set about waiting for the next event in time after waking up this
wait. Might not be a problem but the buildfarm has a tendency to expose a lof
of behavior.

> I think that only prove that no false checksum failure is reported.
> Could one post transition backup reuse the existing corruption mechanism (see
> 010_pg_basebackup.pl) to check that verification resumes?

Good idea, also done in 0002.

> 011_standby_straddle.pl does:
>
> +bgwriter_lru_maxpages = 0
>
> but 010_backup_straddle.pl does not. Should 010_backup_straddle.pl also disable
> bgwriter to preserve dirty pages?

I'm not sure, does it need to?

Another thing I am pondering is to place these tests under PG_TEST_EXTRA.
While 128MB for shared_buffers is pretty moderate, I'm not sure we want to
induce that on a normal BF run. 0002 does some backup cleaning as well as a
pgperltidy and pgindent and some very minor fiddling with test code.

--
Daniel Gustafsson

Attachment Content-Type Size
v4-0001-basebackup-do-not-verify-checksums-on-pages-from-.patch application/octet-stream 29.1 KB
v4-0002-Review-hackery.patch application/octet-stream 10.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-17 09:07:26 Re: basebackup: do not verify checksums on pages written before enabling checksums
Previous Message David Rowley 2026-08-17 09:00:02 Re: redundant double negation prevents IN-subquery pull-up and causes a slower SubPlan