From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Instability of pg_walsummary/002_blocks.pl due to timing |
Date: | 2025-07-07 05:00:01 |
Message-ID: | 6e18e91e-39c0-4204-a3cc-4eb58ea7ff45@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-07-07 05:37:37 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |
Previous Message | shveta malik | 2025-07-07 04:22:53 | Re: Using failover slots for PG-non_PG logical replication |