From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | agrossman(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15033: Segmentation fault running a query |
Date: | 2018-01-27 20:00:07 |
Message-ID: | 17399.1517083207@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> I have encountered a segmentation fault running a particular query.
Given the shape of the query and the fact that it's calling a recursive
function, I'm suspicious that this is caused by a stack overrun that we've
missed checking for. If so, it might not reproduce for someone else,
unless they were running with the exact same physical stack limit (not
max_stack_depth, but the kernel limit) as you are, and a similar compiler.
It would likely be easier all round if you could get a stack trace
from the crash as you observe it. See
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
If my idea is right, the whole trace would be very long (probably
thousands of stack frames) but the first hundred or so ought to
be enough to diagnose.
BTW, seems like there's gotta be a more efficient way to solve your
problem than a 14000-way INTERSECT.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Grossman | 2018-01-27 20:06:48 | Re: BUG #15033: Segmentation fault running a query |
Previous Message | Tom Lane | 2018-01-27 18:57:26 | Re: BUG #15032: Segmentation fault when running a particular query |