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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ron Mackley" <ronm(at)signalpatterns(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4208: Server crashes on insert into gist index
Date: 2008-05-29 14:54:38
Message-ID: 27285.1212072878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ron Mackley 2008-05-29 15:04:30 Re: BUG #4208: Server crashes on insert into gist index
Previous Message Tom Lane 2008-05-29 14:28:30 Re: BUG #4186: set lc_messages does not work