Re: conchuela timeouts since 2021-10-09 system upgrade
От | Andrey Borodin |
---|---|
Тема | Re: conchuela timeouts since 2021-10-09 system upgrade |
Дата | |
Msg-id | 4C43D751-8E0B-478D-B358-7C52BB5AFDAA@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: conchuela timeouts since 2021-10-09 system upgrade (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: conchuela timeouts since 2021-10-09 system upgrade
|
Список | pgsql-bugs |
> 10 нояб. 2021 г., в 09:15, Noah Misch <noah@leadboat.com> написал(а): > > On Thu, Oct 28, 2021 at 07:56:00PM -0700, Noah Misch wrote: >> On Sun, Oct 24, 2021 at 09:03:27PM +0300, Andrey Borodin wrote: >>>> 24 окт. 2021 г., в 19:19, Noah Misch <noah@leadboat.com> написал(а): >>>> These failures started on 2021-10-09, the day conchuela updated from DragonFly >>>> v4.4.3-RELEASE to DragonFly v6.0.0-RELEASE. It smells like a kernel bug. >>>> Since the theorized kernel bug seems not to affect >>>> src/test/subscription/t/015_stream.pl, I wonder if we can borrow a workaround >>>> from other tests. One thing in common with src/test/recovery/t/017_shm.pl and >>>> the newest failure sites is that they don't write anything to the child stdin. >> >>>> If not, does passing the script via stdin, like "pgbench -f- >>>> <script.sql", work around the problem? >>> >>> I'll test it tomorrow, the refactoring does not seem trivial given we use many simultaneous scripts. >> >> Did that work? Commit 7f580aa should make this unnecessary for v12+ >> contrib/amcheck tests, but older branches still need a fix, and 017_shm.pl >> needs a fix in all branches. A backup plan is just to skip affected tests on >> dragonfly 6+. Since the breakage has been limited to so few tests, I'm >> optimistic that a better workaround will present itself. > > Is this still in your queue, or not? The conchuela breakage in > src/test/recovery and v11+v10 src/bin/pgbench is a large source of buildfarm > noise right now. Uh, sorry, this problem fell out of my attention somehow. I'll try to do something with 10 and 11 this or next week. Best regards, Andrey Borodin.
В списке pgsql-bugs по дате отправления: