"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
