From: Tom Lane <tgl@sss.pgh.pa.us>
To: agrossman@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15033: Segmentation fault running a query
In-reply-to: <20180127050845.28812.58244@wrigleys.postgresql.org>
References: <20180127050845.28812.58244@wrigleys.postgresql.org>
Comments: In-reply-to =?utf-8?q?PG_Bug_reporting_form?=
 <noreply@postgresql.org>
	message dated "Sat, 27 Jan 2018 05:08:45 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17398.1517083207.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 27 Jan 2018 15:00:07 -0500
Message-ID: <17399.1517083207@sss.pgh.pa.us>
Precedence: bulk

=3D?utf-8?q?PG_Bug_reporting_form?=3D <noreply@postgresql.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