Hi, On Mon, Aug 17, 2026 at 11:03:31AM +0200, Daniel Gustafsson wrote: > > 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: > > 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.
Yeah, makes sense. > I tried that in the attached 0002. That looks ok, thanks! > 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. The launcher stays blocked and keeps reporting the event until explicitly woken, so I'm not sure I get your point. > > 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. +$node->stop; +$node->corrupt_page_checksum($fcorrupt, 0); +$node->start; The test stops and restarts the node before taking the backup, which resets lastChecksumChangeRecPtr. Should we also test that verification resumes while lastChecksumChangeRecPtr is still set? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
