X-Original-To: pgsql-admin-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id E9D139FB274; Fri, 28 Jul 2006 10:38:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 45190-01; Fri, 28 Jul 2006 10:38:08 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4BF8E9FB272; Fri, 28 Jul 2006 10:37:38 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k6SDbXZn019913; Fri, 28 Jul 2006 09:37:33 -0400 (EDT) To: "Daniel Caune" cc: pgsql-admin@postgresql.org, pgsql-sql@postgresql.org Subject: Re: [SQL] PostgreSQL server terminated by signal 11 In-reply-to: <1E293D3FF63A3740B10AD5AAD88535D202B65042@UBIMAIL1.ubisoft.org> References: <1E293D3FF63A3740B10AD5AAD88535D202B65042@UBIMAIL1.ubisoft.org> Comments: In-reply-to "Daniel Caune" message dated "Fri, 28 Jul 2006 08:49:04 -0400" Date: Fri, 28 Jul 2006 09:37:32 -0400 Message-ID: <19911.1154093852@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.043 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200607/256 X-Sequence-Number: 22502 "Daniel Caune" writes: > Program received signal SIGSEGV, Segmentation fault. > 0x08079e2a in slot_attisnull () > (gdb) bt > #0 0x08079e2a in slot_attisnull () > #1 0x0807a1d0 in slot_getattr () > #2 0x080c6c73 in FormIndexDatum () > #3 0x080c6ef1 in IndexBuildHeapScan () > #4 0x0809b44d in btbuild () > #5 0x0825dfdd in OidFunctionCall3 () > #6 0x080c4f95 in index_build () > #7 0x080c68eb in index_create () > #8 0x08117e36 in DefineIndex () Hmph. gdb is lying to you, because slot_getattr doesn't call slot_attisnull. This isn't too unusual in a non-debug build, because the symbol table is incomplete (no mention of non-global functions). Given that this doesn't happen right away, but only after it's been processing for awhile, we can assume that FormIndexDatum has been successfully iterated many times already, which seems to eliminate theories like the slot or the keycol value being bogus. I'm pretty well convinced now that we're looking at a problem with corrupted data. Can you do a SELECT * FROM (or COPY FROM) the table without error? regards, tom lane