26.07.2024 15:41, Andrew Dunstan wrote:
One way to workaround this is to disable debug_parallel_query in the test
and another I find possible is to set max_parallel_workers = 0.
But wouldn't either of those just be masking the problem?
Yes, I'm inclined to consider this behavior a probl
On 2024-07-26 Fr 7:00 AM, Alexander Lakhin wrote:
25.07.2024 15:00, Alexander Lakhin wrote:
The other question is: why is 005_opclass_damage taking so much time
there?
...
$ make -s check -C src/bin/pg_amcheck/ PROVE_TESTS="t/005*"
PROVE_FLAGS="--timer"
[11:11:53] t/005_opclass_damage.pl
25.07.2024 15:00, Alexander Lakhin wrote:
The other question is: why is 005_opclass_damage taking so much time there?
...
$ make -s check -C src/bin/pg_amcheck/ PROVE_TESTS="t/005*"
PROVE_FLAGS="--timer"
[11:11:53] t/005_opclass_damage.pl .. ok 1370 ms ( 0.00 usr 0.00 sys +
0.10 cusr 0.
On 2024-07-25 Th 8:00 AM, Alexander Lakhin wrote:
Hello hackers,
Please take a look at today's failure [1], that raises several questions
at once:
117/244 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
TIMEOUT 3001.48s exit status 1
180/244 postgresql:pg_amcheck / pg_amcheck/005_o
Hello hackers,
Please take a look at today's failure [1], that raises several questions
at once:
117/244 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade TIMEOUT
3001.48s exit status 1
180/244 postgresql:pg_amcheck / pg_amcheck/005_opclass_damage TIMEOUT
3001.43s exit status
