> On 17 Aug 2026, at 05:07, Bertrand Drouvot <[email protected]> 
> 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: v4-0001-basebackup-do-not-verify-checksums-on-pages-from-.patch
Description: Binary data

Attachment: v4-0002-Review-hackery.patch
Description: Binary data

Reply via email to