Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)
От | Thomas Munro |
---|---|
Тема | Re: lockup in parallel hash join on dikkop (freebsd 14.0-current) |
Дата | |
Msg-id | CA+hUKG+Nz0yR-_SU_uPubBaxQimUPhXy9XYqCUwct3NVjeD4YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: lockup in parallel hash join on dikkop (freebsd 14.0-current) (Alexander Lakhin <exclusion@gmail.com>) |
Список | pgsql-hackers |
On Sat, Sep 9, 2023 at 9:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > Yes, I think we deal with something like that. I can try to deduce a minimum > change that affects reproducing the issue, but may be it's not that important. > Perhaps we now should think of escalating the problem to FreeBSD developers? > I wonder, what kind of reproducer they find acceptable. A standalone C > program only or maybe a script that compiles/installs postgres and runs > our test will do too? We discussed this a bit off-list and I am following up on that. My guess is that this will turn out to be a bad interaction between that optimisation and our (former) habit of forking background workers from inside a signal handler, but let's see... FTR If someone is annoyed by this and just wants their build farm animal not to hang on REL_12_STABLE, via Alexander's later experiments we learned that sysctl kern.sigfastblock_fetch_always=1 fixes the problem.
В списке pgsql-hackers по дате отправления: