On Sun, Jul 06, 2025 at 12:00:00PM +0300, Alexander Lakhin wrote: > This test case is rather new, it was added by f4694e0f3 (from 2025-03-05).
Thanks for the report. > I could reproduce this failure within 20 test runs with the following > modification: > --- a/src/backend/postmaster/walsummarizer.c > +++ b/src/backend/postmaster/walsummarizer.c > @@ -1544,6 +1544,7 @@ summarizer_read_local_xlog_page(XLogReaderState *state, > * so we don't tight-loop. > */ > ProcessWalSummarizerInterrupts(); > +pg_usleep(1000000); > summarizer_wait_for_wal(); > > Michael, as you added the test case, could you please have a look? I'm failing to reproduce it, unfortunately. It looks like just a timing issue with the reports, so the best option I can think of here would be to switch the test to do a wait until the stats have been generated, leading to the attached. Do you still see the problem with that in place? -- Michael
diff --git a/src/bin/pg_walsummary/t/002_blocks.pl b/src/bin/pg_walsummary/t/002_blocks.pl
index 270332780a45..0f98c7df82e6 100644
--- a/src/bin/pg_walsummary/t/002_blocks.pl
+++ b/src/bin/pg_walsummary/t/002_blocks.pl
@@ -47,11 +47,12 @@ EOM
ok($result, "WAL summarization caught up after insert");
# The WAL summarizer should have generated some IO statistics.
-my $stats_reads = $node1->safe_psql(
+$node1->poll_query_until(
'postgres',
- qq{SELECT sum(reads) > 0 FROM pg_stat_io
- WHERE backend_type = 'walsummarizer' AND object = 'wal'});
-is($stats_reads, 't', "WAL summarizer generates statistics for WAL reads");
+ q{SELECT sum(reads) > 0 FROM pg_stat_io
+ WHERE backend_type = 'walsummarizer' AND object = 'wal'})
+ or die
+ "Timed out while waiting for WAL summarizer to generate statistics for WAL reads";
# Find the highest LSN that is summarized on disk.
my $summarized_lsn = $node1->safe_psql('postgres', <<EOM);
signature.asc
Description: PGP signature
