From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stefan Tzeggai <tzeggai(at)empirica-systeme(dot)de> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Segfault 11 on PG10 with max_parallel_workers_per_gather>3 |
Date: | 2017-10-25 20:41:57 |
Message-ID: | 23727.1508964117@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stefan Tzeggai <tzeggai(at)empirica-systeme(dot)de> writes:
> I also tried to get a sensible stack trace. I attached 9 gdb to all
> postgres-pids and when I triggered the crash, two of the gdb had some
> output and produced something on 'bt'. Attached..
Those look like normal operation --- SIGUSR1 isn't a crash condition,
it's what PG normally uses to wake up a sleeping process. If you
want to attach gdb before provoking the crash, you need to tell it
to ignore SIGUSR1 (I think "handle SIGUSR1 pass nostop noprint"
is the right incantation).
It might be easier to enable core files ("ulimit -c unlimited" before
starting the postmaster) and then gdb the core files.
> If I would be able to dump the relevant data from my db and I would be
> able to reproduce the crash with it on a fresh PG10 install - Would
> anyone have time to look at it? I guess its would no more than 50Mb...
Sure, I or somebody else would look at it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-10-25 21:37:03 | Re: BUG #14872: libpq requires a home directory |
Previous Message | Stefan Tzeggai | 2017-10-25 20:33:13 | Re: Segfault 11 on PG10 with max_parallel_workers_per_gather>3 |