Re: BUG #4208: Server crashes on insert into gist index
От | Tom Lane |
---|---|
Тема | Re: BUG #4208: Server crashes on insert into gist index |
Дата | |
Msg-id | 27285.1212072878@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #4208: Server crashes on insert into gist index ("Ron Mackley" <ronm@signalpatterns.com>) |
Ответы |
Re: BUG #4208: Server crashes on insert into gist index
|
Список | pgsql-bugs |
"Ron Mackley" <ronm@signalpatterns.com> writes: > We've been seeing infrequent crashes of the postgres. This is version 8.2.6 > running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs. > We captured a core file and here is the stack trace: > (gdb) bt > #0 0x0000000000615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585 > #1 0x00002aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898 > #2 0x0000000000602b14 in DirectFunctionCall2 (func=0x2aaace72aa00 > <cube_inter>, arg1=46913066890008, arg2=5) at fmgr.c:888 > #3 0x00002aaace72a73b in g_cube_picksplit (fcinfo=<value optimized out>) at > cube.c:571 Hmmm ... just looking at the code, I bet what is happening is that the "swap" path in cube_inter is taken, and then the comparisons in PG_FREE_IF_COPY get confused and try to pfree values that were not separately allocated. But if that's the story, why does cube_inter not show a crash rate approaching 50%? Maybe most people only use it on cubes of the same dimensionality. Does your gist index contain cubes of varying numbers of dimensions? regards, tom lane
В списке pgsql-bugs по дате отправления: