Re: Instability of pg_walsummary/002_blocks.pl due to timing - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Instability of pg_walsummary/002_blocks.pl due to timing
Date
Msg-id 6e18e91e-39c0-4204-a3cc-4eb58ea7ff45@gmail.com
Whole thread Raw
In response to Instability of pg_walsummary/002_blocks.pl due to timing  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-hackers
Hello Michail,

07.07.2025 03:18, Michael Paquier wrote:
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?

I'm sorry for not being accurate enough -- I forgot to mention that I
replicated the config from culicidae, and now I see that "fsync=on"
is needed to reproduce the failure for me (though maybe).

With:
./configure -q --enable-cassert --enable-debug --enable-tap-tests && make -s -j8
echo "fsync=on" >/tmp/temp.config
for i in {1..100}; do echo "ITERATION $i"; TEMP_CONFIG=/tmp/temp.config PROVE_TESTS="t/002*" make -s check -C src/bin/pg_walsummary/ || break; done
I got failures on iterations 3, 5, 1. With your patch applied, I got 100
iterations passed.

Thank you for the fix!

Best regards,
Alexander

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Using failover slots for PG-non_PG logical replication
Next
From: Tatsuo Ishii
Date:
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options