Re: Recent 027_streaming_regress.pl hangs
От | Andrew Dunstan |
---|---|
Тема | Re: Recent 027_streaming_regress.pl hangs |
Дата | |
Msg-id | 137979d0-943e-42c8-ab53-1244b30a6623@dunslane.net обсуждение исходный текст |
Ответ на | Re: Recent 027_streaming_regress.pl hangs (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Recent 027_streaming_regress.pl hangs
|
Список | pgsql-hackers |
On 2024-07-25 Th 12:00 AM, Alexander Lakhin wrote: > Hello Andrew, > > 04.06.2024 13:00, Alexander Lakhin wrote: >> Also, 027_stream_regress still fails due to the same reason: >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2024-05-22%2021%3A55%3A03 >> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2024-05-22%2021%3A54%3A50 >> >> (It's remarkable that these two animals failed at the same time.) >> > > It looks like crake is failing now due to other reasons (not just > concurrency) — it produced 10+ failures of the > 027_stream_regress test starting from July, 9. > > The first such failure on REL_16_STABLE was [1], and that was the > first run > with 'PG_TEST_EXTRA' => '... wal_consistency_checking'. > > There is one known issue related to wal_consistency_checking [2], but I > see no "incorrect resource manager data checksum" in the failure log... > > Moreover, the first such failure on REL_17_STABLE was [3], but that run > was performed without wal_consistency_checking, as far as I can see. > > Can that failure be also related to the OS upgrade (I see that back in > June crake was running on Fedora 39, but now it's running on Fedora 40)? > > So maybe we have two factors combined or there is another one? > > [1] > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-07-17%2014%3A56%3A09 > [2] > https://www.postgresql.org/message-id/055bb33c-bccc-bc1d-c2f8-8598534448ac@gmail.com > [3] > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-07-09%2021%3A37%3A04 Unlikely. The change in OS version was on June 17, more than a month ago. But yes we do seem to have seen a lot of recovery_check failures on crake in the last 8 days, which is roughly when I changed PG_TEST_EXTRA to get more coverage. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: