On Fri, Dec 8, 2017 at 12:47 AM, Bernd Helmle <mailings@oopsware.de> wrote:
> A customer recently reported a crash in a postgres backend. The backend
> encountered a SIGSEGV, crashing during SELECTs from a fairly
> complicated view using a grouping set directive. I've managed to
> reproduce it by tracking it down to a specific SELECT, but
> unfortunately couldn't yet manage to strip it down to a small,
> repeatable test case which doesn't involve the whole (sensitive)
> dataset. I'm reporting my findings so far, maybe it helps to track it
> down already.
Hmm. Even if you cannot reproduce an isolated test case, could it be
possible to get an idea of the shape the SELECT query involved and of
the schema plus the view? No need for sensitive data here. This would
help in reproducing a test case. What are also the sizes involved?
Even a small data set with work_mem low should trigger the problem?
> I've tested this so far against very current REL9_6_STABLE and
> REL9_5_STABLE and got them to crash with the same backtrace. The crash
> is dependent on the chosen plan, experiments with work_mem show that
> the crash seems to happen only if you get external sorts into the
> execution plan.
> REL10_STABLE seems not affected, as my extracted application query
> doesn't crash there.
That's one thing to begin with. So HEAD is not affected as well?
--
Michael