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+zUu1TdaqhJpc1dmq8Zdc=RHxv9o0ipOt7o-Z6iUB9RQ@mail.gmail.com
Whole thread Raw
In response to Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)
List pgsql-hackers
On Thu, Aug 31, 2023 at 2:32 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Thu, Aug 31, 2023 at 12:16 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> > I have another case of this on dikkop (on 11 again). Is there anything
> > else we'd want to try? Or maybe someone would want access to the machine
> > and do some investigation directly?

Hmm.  No conclusion tonight but I think it's weird.  We have:

bsd@generic:/mnt/data/buildfarm $ ps x -O wchan | grep 52663
52663 select  -  Is   0:07.40 postgres: bsd regression [local] SELECT (postgres)
52731 select  -  Is   0:00.09 postgres: parallel worker for PID 52663
  (postgres)
52732 select  -  Is   0:00.06 postgres: parallel worker for PID 52663
  (postgres)
81525 piperd  0  S+   0:00.01 grep 52663

wchan=select means sleeping in poll()/select().

bsd@generic:/mnt/data/buildfarm $ procstat -i 52732 | grep USR1
52732 postgres         USR1     P-C
bsd@generic:/mnt/data/buildfarm $ procstat -j 52732 | grep USR1
52732 100121 postgres         USR1     --

We have a signal that is pending and not blocked, so I don't
immediately know why poll() hasn't returned control.



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Should we use MemSet or {0} for struct initialization?
Next
From: Dilip Kumar
Date:
Subject: Re: pg_stat_get_backend_subxact() and backend IDs?