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

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@signalpatterns.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@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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs