From: | Chris Curvey <chris(at)chriscurvey(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: postgres segfaulting on pg_restore |
Date: | 2011-05-04 12:12:06 |
Message-ID: | BANLkTiko7Aaa1VR1UZDWk_ot1dBicC+x7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
>
> It occurred to me that a simple explanation for a core dump there would
> be if something had scribbled past the end of the preceding palloc
> chunk. That would tend to clobber the "context" link of the palloc
> chunk after it, which would send GetMemoryChunkSpace off into
> never-never land following a trashed pointer.
>
> That doesn't get us very much closer to a solution, but it does suggest
> that you might learn something if you try this with an assert-enabled
> build (configure --enable-cassert). Also, are there any contrib modules
> or third-party add-on modules or home-brew C functions that you're using?
>
>
in reverse order: no third-party, no contrib, no home-brew C. here is a
stack trace from a fresh build of 9.1 beta 1 built with enable-cassert.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000744777 in AllocSetAlloc (context=0x13f6d08, size=16) at
aset.c:639
639 Assert(chunk->size >= size);
#0 0x0000000000744777 in AllocSetAlloc (context=0x13f6d08, size=16) at
aset.c:639
#1 0x000000000074d07b in readtup_index (state=0x1453568,
stup=0x7fffa5135010, tapenum=0, len=<value optimized out>) at
tuplesort.c:3258
#2 0x000000000074a57c in mergeprereadone (state=0x1453568, srcTape=0) at
tuplesort.c:2157
#3 0x000000000074a9d3 in tuplesort_gettuple_common (state=0x1453568,
forward=<value optimized out>, stup=0x7fffa51350a0, should_free=<value
optimized out>) at tuplesort.c:1491
#4 0x000000000074ac96 in tuplesort_getindextuple (state=0x13f6d08,
forward=16 '\020', should_free=0x10 <Address 0x10 out of bounds>) at
tuplesort.c:1580
#5 0x000000000048d076 in _bt_load (btspool=<value optimized out>,
btspool2=<value optimized out>) at nbtsort.c:786
#6 _bt_leafbuild (btspool=<value optimized out>, btspool2=<value optimized
out>) at nbtsort.c:224
#7 0x000000000048788c in btbuild (fcinfo=<value optimized out>) at
nbtree.c:142
#8 0x000000000072d55c in OidFunctionCall3Coll (functionId=<value optimized
out>, collation=0, arg1=140144035752040, arg2=21827704, arg3=20972800) at
fmgr.c:1645
#9 0x00000000004d095d in index_build (heapRelation=0x7f75d377e868,
indexRelation=0x14d1078, indexInfo=0x1400500, isprimary=<value optimized
out>, isreindex=0 '\000') at index.c:1737
#10 0x00000000004d31c5 in index_create (heapRelation=<value optimized out>,
indexRelationName=<value optimized out>, indexRelationId=<value optimized
out>, indexInfo=0x1400500, indexColNames=<value optimized out>,
accessMethodObjectId=<value optimized out>, tableSpaceId=0,
collationObjectId=0x1400618, classObjectId=0x1400638, coloptions=0x1400658,
reloptions=0, isprimary=1 '\001', isconstraint=1 '\001', deferrable=0
'\000', initdeferred=0 '\000', allow_system_table_mods=0 '\000',
skip_build=0 '\000', concurrent=0 '\000') at index.c:1067
#11 0x000000000054bd81 in DefineIndex (heapRelation=<value optimized out>,
indexRelationName=<value optimized out>, indexRelationId=<value optimized
out>, accessMethodName=<value optimized out>, tableSpaceName=<value
optimized out>, attributeList=0x85cf3e, predicate=0x0, options=0x0,
exclusionOpNames=0x0, unique=1 '\001', primary=1 '\001', isconstraint=1
'\001', deferrable=<value optimized out>, initdeferred=<value optimized
out>, is_alter_table=1 '\001', check_rights=1 '\001', skip_build=0 '\000',
quiet=0 '\000', concurrent=<value optimized out>) at indexcmds.c:397
#12 0x000000000055b115 in ATExecAddIndex (tab=0x13bb038, rel=<value
optimized out>, stmt=0x14001d8, is_rebuild=0 '\000', lockmode=<value
optimized out>) at tablecmds.c:5173
#13 0x00000000005653c9 in ATExecCmd (wqueue=<value optimized out>,
tab=0x13bb038, rel=0x7f75d377e868, cmd=0x14001a0, lockmode=6) at
tablecmds.c:3074
#14 0x0000000000565fc5 in ATRewriteCatalogs (rel=<value optimized out>,
cmds=<value optimized out>, recurse=<value optimized out>, lockmode=6) at
tablecmds.c:3001
#15 ATController (rel=<value optimized out>, cmds=<value optimized out>,
recurse=<value optimized out>, lockmode=6) at tablecmds.c:2735
#16 0x000000000066bda5 in standard_ProcessUtility (parsetree=<value
optimized out>, queryString=0x13ad538 "ALTER TABLE ONLY transactions\n
ADD CONSTRAINT transactions_pkey PRIMARY KEY (id);", params=0x0,
isTopLevel=1 '\001', dest=0x13ae5a8, completionTag=0x7fffa5135e30 "") at
utility.c:767
#17 0x00000000006674b7 in PortalRunUtility (portal=0x1329078,
utilityStmt=0x13ae220, isTopLevel=16 '\020', dest=0x13ae5a8,
completionTag=0x7fffa5135e30 "") at pquery.c:1184
#18 0x0000000000668740 in PortalRunMulti (portal=0x1329078, isTopLevel=1
'\001', dest=<value optimized out>, altdest=0x13ae5a8,
completionTag=0x7fffa5135e30 "") at pquery.c:1315
#19 0x0000000000668f52 in PortalRun (portal=<value optimized out>,
count=<value optimized out>, isTopLevel=16 '\020', dest=<value optimized
out>, altdest=<value optimized out>, completionTag=<value optimized out>) at
pquery.c:813
#20 0x000000000066518b in exec_simple_query (query_string=<value optimized
out>) at postgres.c:1018
#21 0x000000000066615b in PostgresMain (argc=<value optimized out>,
argv=<value optimized out>, username=<value optimized out>) at
postgres.c:3924
#22 0x000000000061d2f1 in BackendRun () at postmaster.c:3600
#23 BackendStartup () at postmaster.c:3285
#24 ServerLoop () at postmaster.c:1454
#25 0x000000000061fc9d in PostmasterMain (argc=3, argv=0x1305880) at
postmaster.c:1115
#26 0x00000000005b9720 in main (argc=3, argv=0x1305870) at main.c:199
--
e-Mail is the equivalent of a postcard written in pencil. This message may
not have been sent by me, or intended for you. It may have been read or
even modified while in transit. e-Mail disclaimers have the same force in
law as a note passed in study hall. If your corporate attorney says that
you need an disclaimer in your signature, you need a new corporate attorney.
From | Date | Subject | |
---|---|---|---|
Next Message | Raymond O'Donnell | 2011-05-04 12:22:55 | Re: postgresql not updating the sequence |
Previous Message | Jens Wilke | 2011-05-04 12:11:15 | undead index |