Re: lockup in parallel hash join on dikkop (freebsd 14.0-current) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)
Date
Msg-id CA+hUKG+Nz0yR-_SU_uPubBaxQimUPhXy9XYqCUwct3NVjeD4YQ@mail.gmail.com
Whole thread Raw
In response to Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)  (Alexander Lakhin <exclusion@gmail.com>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Query execution in Perl TAP tests needs work
Next
From: Jacob Champion
Date:
Subject: Re: Row pattern recognition