Re: PostgreSQL crashes with SIGSEGV
От | Michael Paquier |
---|---|
Тема | Re: PostgreSQL crashes with SIGSEGV |
Дата | |
Msg-id | CAB7nPqSpCQQ5h+-v9-8AoEXycFZAcwCSMP619MSG_MaN40swzA@mail.gmail.com обсуждение исходный текст |
Ответ на | PostgreSQL crashes with SIGSEGV (Bernd Helmle <mailings@oopsware.de>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: