Skip site navigation (1) Skip section navigation (2)

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

From: Ron Mackley <ronm(at)signalpatterns(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4208: Server crashes on insert into gist index
Date: 2008-05-29 15:04:30
Message-ID: 318A281C-2A5F-4F85-AEE4-50F5A52B18AD@signalpatterns.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom,

Thanks for the quick response. No:

sp_hub_production=# select distinct cube_dim(attribute_vector) from  
user_attribute_vectors;
  cube_dim
----------
         5
(1 row)

In the past we had a problem where runt vectors found their way into  
the table, but we deleted them and try to detect them on their way in.

This happened once before and then stopped. That's when we started  
capturing core files. I suspect that it happens when our user base  
grows enough to force a split on insert with just the right record. We  
will probably see a fallow period and it will happen again after we  
get another couple thousand users.

Ron

Ron Mackley
Manager, Software Development
Signal Patterns
ronm(at)signalpatterns(dot)com

==========================================================
The information contained in this email message may be privileged,  
confidential and protected from disclosure. If you are not the  
intended recipient, any distribution or copying is strictly  
prohibited. If you think that you have received this email message in  
error, please notify the sender by reply email and delete the message  
and any attachments.




On 29 May 2008, at 10:54 AM, Tom Lane wrote:

> "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

pgsql-bugs by date

Next:From: Tom LaneDate: 2008-05-29 16:33:51
Subject: Re: BUG #4208: Server crashes on insert into gist index
Previous:From: Tom LaneDate: 2008-05-29 14:54:38
Subject: Re: BUG #4208: Server crashes on insert into gist index

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group