Re: signal 11 segfaults with parallel workers

FWIW, the database crashed again tonight. It hasn't been quiet enough yet
to be able to restart it in a controlled fashion to enable cores.
Hopefully I'll get a chance this weekend!

2017-07-27 23:01:20.411 UTC LOG: worker process: parallel worker for
PID 31472 (PID 2186) was terminated by signal 11: Segmentation fault

Since I didn't have statement logging and debug turned on this time, I can
only guess which query seg faulted.

Is enabling DEBUG in the postgresql.conf sufficient to enable debug symbols
in the core, or do I have to rebuild the postgresql binaries to get that?
Is the core of any use without debug symbols enabled?

On Wed, Jul 26, 2017 at 12:26 PM, Rick Otten <rottenwindfish(at)gmail(dot)com>
wrote:

> I'll restart the database tonight to pick up the ulimit change and let you
> know if I capture a core file in the near future.
>
>
> On Wed, Jul 26, 2017 at 11:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Rick Otten <rottenwindfish(at)gmail(dot)com> writes:
>> > I don't have any core files. I suppose that is something I have to
>> enable
>> > specifically? I'm game to turn it on in case we core dump again.
>>
>> If you're not seeing core files, you probably need to take measures
>> to make the postmaster run with "ulimit -c unlimited". It's fairly
>> common for daemon processes to get launched under "ulimit -c 0"
>> by default, for largely-misguided-imo security reasons.
>>
>> regards, tom lane
>>
>
>