Re: PostgreSQL crashes with SIGSEGV

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: PostgreSQL crashes with SIGSEGV
Date: 2017-12-08 02:08:12
Message-ID: CAB7nPqSpCQQ5h+-v9-8AoEXycFZAcwCSMP619MSG_MaN40swzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Fri, Dec 8, 2017 at 12:47 AM, Bernd Helmle <mailings(at)oopsware(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2017-12-08 02:23:28 Re: PostgreSQL crashes with SIGSEGV
Previous Message Michael Paquier 2017-12-08 01:37:15 Re: BUG #14952: COPY fails to fill in IDENTITY column default value

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-12-08 02:23:28 Re: PostgreSQL crashes with SIGSEGV
Previous Message Thomas Munro 2017-12-08 02:03:50 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)