Hi,
On Mon, Aug 17, 2026 at 11:03:31AM +0200, Daniel Gustafsson wrote:
> > On 17 Aug 2026, at 05:07, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> 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