Re: Segfault 11 on PG10 with max_parallel_workers_per_gather>3

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

In response to

Responses

Browse pgsql-bugs by date

  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