Re: Instability of pg_walsummary/002_blocks.pl due to timing
От | Alexander Lakhin |
---|---|
Тема | Re: Instability of pg_walsummary/002_blocks.pl due to timing |
Дата | |
Msg-id | 6e18e91e-39c0-4204-a3cc-4eb58ea7ff45@gmail.com обсуждение исходный текст |
Ответ на | Instability of pg_walsummary/002_blocks.pl due to timing (Alexander Lakhin <exclusion@gmail.com>) |
Список | pgsql-hackers |
Hello Michail,
07.07.2025 03:18, Michael Paquier wrote:
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 по дате отправления: