Re: BUG #15033: Segmentation fault running a query

Oh, I have little doubt there's a better way to solve the actual
problem--this actually resulted from some buggy code that passed a bunch of
unexpected arguments to a query generating function. I would note that this
did reproduce for me on a different system with some different specs.

I will follow-up with a stack trace. In the meantime, a more accessible
version of the reproduction script has been placed at the following address:

https://fleetinventory.com/media/static/pg10crash.sql

On Sat, Jan 27, 2018 at 3:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?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
>