Re: catalog corruption bug - Mailing list pgsql-hackers

On Sun, 8 Jan 2006, Tom Lane wrote:

> Yeah, that's not very surprising.  Running the forced-cache-resets
> function will definitely expose that catcache bug pretty quickly.
> You'd need to apply the patches I put in yesterday to have a system
> that has any chance of withstanding that treatment for any length of time.
>
> > I think I am going to just run without the function running this time and
> > see if it does the duplicate type error and if it will generate two cores.

I ran without that function you made, and it got the error, but not a
crash.  I stuck an Assert(false) right before the ereport for that
particular error, and I did end up with a core there, but I don't see
anything out of the ordinary (what little I know of the ordinary ;)

#0  0x00002aaaab8a0cf9 in kill () from /usr/lib64/libc.so.6
#1  0x00002aaaab8a0a3d in raise () from /usr/lib64/libc.so.6
#2  0x00002aaaab8a1c82 in abort () from /usr/lib64/libc.so.6
#3  0x00000000005f9878 in ExceptionalCondition (   conditionName=0x2c53 <Address 0x2c53 out of bounds>,   errorType=0x6
<Address0x6 out of bounds>, fileName=0x0,
 
lineNumber=-1)   at assert.c:51
#4  0x0000000000460967 in _bt_doinsert (rel=0x2aaaaab05568,
btitem=0xbec2c0,   index_is_unique=1 '\001', heapRel=0x8bf0f0) at nbtinsert.c:247
#5  0x0000000000463773 in btinsert (fcinfo=0x2c53) at nbtree.c:228
#6  0x00000000005fe869 in FunctionCall6 (flinfo=0x8, arg1=6, arg2=0,   arg3=18446744073709551615, arg4=0, arg5=0,
arg6=0)at fmgr.c:1267
 
#7  0x000000000045bf4f in index_insert (indexRelation=0x2aaaaab05568,   values=0x7fffffdfde20, isnull=0x7fffffdfde00
"",heap_t_ctid=0xbebeac,   heapRelation=0x8bf0f0, check_uniqueness=1 '\001') at indexam.c:215
 
#8  0x000000000048f8fa in CatalogIndexInsert (indstate=0x2c53,   heapTuple=0xbebb88) at indexing.c:124
#9  0x000000000048f994 in CatalogUpdateIndexes (heapRel=0x2c53,   heapTuple=0xbebea8) at indexing.c:149
#10 0x000000000049bc67 in TypeCreate (typeName=0x7fffffdfe3e0
"push_tmp",   typeNamespace=11057063, relationOid=12171371, relationKind=114 'r',   internalSize=-16728, typeType=99
'c',typDelim=44 ',',   inputProcedure=2290, outputProcedure=2291, receiveProcedure=2402,   sendProcedure=2403,
analyzeProcedure=0,elementType=0, baseType=0,   defaultTypeValue=0x0, defaultTypeBin=0x0, passedByValue=-16 '',
alignment=100'd', storage=120 'x', typeMod=-1, typNDims=0,   typeNotNull=0 '\0') at pg_type.c:316
 
#11 0x000000000048c361 in heap_create_with_catalog (   relname=0x7fffffdfe3e0 "push_tmp", relnamespace=11057063,
reltablespace=0,relid=12171371, ownerid=16384, tupdesc=0xbeb8e8,   relkind=114 'r', shared_relation=0 '\0',
oidislocal=0'\0',
 
oidinhcount=0,   oncommit=ONCOMMIT_DROP, allow_system_table_mods=0 '\0') at heap.c:634
#12 0x00000000004de220 in DefineRelation (stmt=0x93fc30, relkind=114 'r')   at tablecmds.c:423
#13 0x000000000058bfd0 in ProcessUtility (parsetree=0x93fc30, params=0x0,   dest=0x814b40, completionTag=0x0) at
utility.c:497
#14 0x0000000000515cb5 in _SPI_execute_plan (plan=0x93f9a8,
Values=0x9c5798,   Nulls=0x9c57b8 "~", '\177' <repeats 199 times>..., snapshot=0x0,   crosscheck_snapshot=0x0,
read_only=0'\0', tcount=0) at spi.c:1449
 
#15 0x00000000005165fc in SPI_execute_plan (plan=0x93f9a8,
Values=0x9c5798,   Nulls=0x9c57b8 "~", '\177' <repeats 199 times>..., read_only=0 '\0',   tcount=0) at spi.c:336
#16 0x00002aaaac95d8a4 in exec_stmts (estate=0x7fffffdfe950, stmts=0x6)   at pl_exec.c:2280
#17 0x00002aaaac95ebc2 in exec_stmt_block (estate=0x7fffffdfe950,   block=0x8f2c70) at pl_exec.c:936
#18 0x00002aaaac95f5ab in plpgsql_exec_function (func=0x913bc8,   fcinfo=0x7fffffdfea90) at pl_exec.c:286
#19 0x00002aaaac9573f5 in plpgsql_call_handler (fcinfo=0x7fffffdfea90)   at pl_handler.c:123
#20 0x0000000000501a74 in ExecMakeFunctionResult (fcache=0x90a7f0,   econtext=0x90a6c0, isNull=0x90ae38
"\177~\177\177\177\177\177\177!\006",   isDone=0x90aef0) at execQual.c:1095
#21 0x0000000000505543 in ExecProject (projInfo=0x90ae58,   isDone=0x7fffffdfeef4) at execQual.c:3669
#22 0x000000000050ff5a in ExecResult (node=0x90a5a8) at nodeResult.c:157
#23 0x000000000050034d in ExecProcNode (node=0x90a5a8) at
execProcnode.c:306
#24 0x00000000004ff5ea in ExecutorRun (queryDesc=0x90a5a8,   direction=ForwardScanDirection, count=0) at
execMain.c:1110
#25 0x000000000058a5de in PortalRunSelect (portal=0x8e6c68, forward=1
'\001',   count=0, dest=0x8dad30) at pquery.c:794
#26 0x000000000058abdf in PortalRun (portal=0x8e6c68,   count=9223372036854775807, dest=0x8dad30, altdest=0x8dad30,
completionTag=0x7fffffdff320"") at pquery.c:646
 
#27 0x0000000000588fcb in PostgresMain (argc=9333864, argv=0x8dac18,   username=0x8853f0 "jeremyd") at postgres.c:1754
#28 0x000000000055e20a in ServerLoop () at postmaster.c:2853
#29 0x000000000055f9f9 in PostmasterMain (argc=3, argv=0x8832e0)   at postmaster.c:943
#30 0x000000000051fb83 in main (argc=3, argv=0x8832e0) at main.c:256

>
> Please also look at putting together a test case so others can poke at
> this.

I sent some emails around which should hopefully set this in motion.