segv's on CREATE INDEX with recent HEAD...

Don't know whether or not this is preferred here or on hackers, but, I
just updated my development database to a snapshot from today and have
been getting the following backtrace when importing a dump from before
earlier today. It looks as though something's tromping on variable.

pid 68526 (postgres), uid 70: exited on signal 11 (core dumped)
#0 0x0810c29d in ExecEvalVar (variable=0x2, econtext=0x83cc0a0, isNull=0xbfbfed70 "") at execQual.c:403
#1 0x0810aa67 in ExecEvalExpr (expression=0x83cc208, econtext=0x83cc0a0, isNull=0xbfbfed70 "", isDone=0xbfbfecbc) at execQual.c:1985
#2 0x08109e60 in ExecMakeFunctionResult (fcache=0x83cc100, econtext=0x83cc0a0, isNull=0xbfbfee2b "", isDone=0x0) at execQual.c:641
#3 0x0810ab46 in ExecEvalExpr (expression=0x83cc100, econtext=0x83cc0a0, isNull=0xbfbfee2b "", isDone=0x83cc0a0) at execQual.c:2012
#4 0x0810bcd9 in ExecEvalExprSwitchContext (expression=0x8316b70, econtext=0x83cc0a0, isNull=0x8316b70 "\b", isDone=0x8316b70)
at execQual.c:2129
#5 0x080a5a0c in FormIndexDatum (indexInfo=0x83f9c18, heapTuple=0x8351938, heapDescriptor=0x8316b70, estate=0x83cc018, datum=0xbfbfeec0,
nullv=0xbfbfeea0 "\b)/\b") at index.c:955
#6 0x080a6529 in IndexBuildHeapScan (heapRelation=0xbfbfeec0, indexRelation=0x8416468, indexInfo=0x83f9c18,
callback=0x8087eb0 <btbuildCallback>, callback_state=0xbfbfef90) at index.c:1625
#7 0x08086e1b in btbuild (fcinfo=0x8316b70) at nbtree.c:129
#8 0x081ffd60 in OidFunctionCall3 (functionId=137456496, arg1=137456496, arg2=137456496, arg3=137456496) at fmgr.c:1277
#9 0x080a62a9 in index_build (heapRelation=0x8316b70, indexRelation=0x2, indexInfo=0x8316b70) at index.c:1398
#10 0x080a530e in index_create (heapRelationId=33576, indexRelationName=0x834c350 "t_udx", indexInfo=0x83f9c18,
accessMethodObjectId=137456496, classObjectId=0x83f9ca0, primary=0 '\0', isconstraint=0 '\0', allow_system_table_mods=0 '\0')
at index.c:750
#11 0x080e332d in DefineIndex (heapRelation=0x83f9c18, indexRelationName=0x834c350 "t_udx", accessMethodName=0x82165c6 "btree",
attributeList=0x834c510, unique=1 '\001', primary=0 '\0', isconstraint=0 '\0', predicate=0x0, rangetable=0x8328) at indexcmds.c:238
#12 0x0818709e in ProcessUtility (parsetree=0x834c528, dest=0x0, completionTag=0x834c528 "\002") at utility.c:736
#13 0x08185299 in PortalRunUtility (portal=0x83a0018, query=0x0, dest=0x834c568, completionTag=0x0) at pquery.c:737
#14 0x08185513 in PortalRunMulti (portal=0x83a0018, dest=0x834c568, altdest=0x834c568, completionTag=0xbfbff3a0 "") at pquery.c:801
#15 0x08184df4 in PortalRun (portal=0x83a0018, count=2147483647, dest=0x834c568, altdest=0x8316b70, completionTag=0xbfbff3a0 "")
at pquery.c:465
#16 0x081834b3 in exec_simple_query (query_string=0x834c030 "CREATE UNIQUE INDEX t_udx ON s.t (LOWER(a));")
at postgres.c:853
#17 0x08181eea in PostgresMain (argc=4, argv=0x82db9d8, username=0x82db9a8 "nxadba") at postgres.c:2730
#18 0x0815948d in BackendFork (port=0x82e6000) at postmaster.c:2473
#19 0x08158e54 in BackendStartup (port=0x82e6000) at postmaster.c:2095
#20 0x081575ec in ServerLoop () at postmaster.c:1049
#21 0x08156e68 in PostmasterMain (argc=1, argv=0x82d9030) at postmaster.c:829
#22 0x08123b63 in main (argc=1, argv=0xbfbffcb8) at main.c:211
#23 0x0806c0a5 in _start ()

It looks like the change that went in on 1.128 is the culprit simply
because it's the only change in this function since the last stable
snapshot. I can consitently reproduce this with one of my schemas if
someone needs more debugging information, point me in the right
direction for where you'd like me to attach gdb. I haven't been able
to get a use case bottled up, but with a backtrace, I'm not that
worried.

-sc

--
Sean Chittenden