Re: BUG #4208: Server crashes on insert into gist index

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

"Ron Mackley" <ronm(at)signalpatterns(dot)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