Re: [BUGS] signal 11 segfaults with parallel workers
| От | Rick Otten |
|---|---|
| Тема | Re: [BUGS] signal 11 segfaults with parallel workers |
| Дата | |
| Msg-id | CAMAYy4JNUxy41CZh0rrCBkbDyX=z_fNeTyPwg_0X4f01oM_jKg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] signal 11 segfaults with parallel workers (Rick Otten <rottenwindfish@gmail.com>) |
| Ответы |
Re: [BUGS] signal 11 segfaults with parallel workers
|
| Список | pgsql-bugs |
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@gmail.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@sss.pgh.pa.us> wrote:Rick Otten <rottenwindfish@gmail.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
В списке pgsql-bugs по дате отправления: