Maybe someone gets an idea by looking at the stack trace at the moment of
the error message:

(gdb) where
#0  fmgr_info (procedureId=683, finfo=0x82154f4) at fmgr.c:179
#1  0x8162739 in CatalogCacheInitializeCache (cache=0x8215478, 
    relation=0x81f03b0) at catcache.c:217
#2  0x8163e3a in SearchSysCache (cache=0x8215478, v1=135759431, v2=1, 
    v3=3221222512, v4=0) at catcache.c:837
#3  0x8169076 in SearchSysCacheTuple (cacheId=8, key1=135759431, key2=1, 
    key3=3221222512, key4=0) at syscache.c:508
#4  0x8096869 in TypeCreate (typeName=0x82136a0 "pg_inherits", 
    relationOid=16536, internalSize=4, externalSize=4, typeType=99 'c', 
    typDelim=44 ',', inputProcedure=0x8178647 "int4in", 
    outputProcedure=0x817863f "int4out", receiveProcedure=0x8178647 "int4in", 
    sendProcedure=0x817863f "int4out", elementTypeName=0x0, 
    defaultTypeValue=0x817863d "-", passedByValue=1 '\001', alignment=105 'i')
    at pg_type.c:408
#5  0x808e7ec in addNewRelationType (typeName=0x82136a0 "pg_inherits", 
    new_rel_oid=16536) at heap.c:724
#6  0x808e8c9 in heap_create_with_catalog (relname=0x82136a0 "pg_inherits", 
    tupdesc=0x82137a8, relkind=114 'r') at heap.c:798
#7  0x8089fae in Int_yyparse () at bootparse.y:182
#8  0x808c4d4 in BootstrapMain (argc=6, argv=0xbffffb18) at bootstrap.c:426
#9  0x80c8103 in main (argc=7, argv=0xbffffb14) at main.c:100

The structure cache points to starts with:

$7 = {relationId = 1255, indexId = 0, cc_relname = 0x819d780 "pg_proc", 
  cc_indname = 0x819d760 "pg_proc_proname_narg_type_index", 
  cc_iscanfunc = 0x8092760 <ProcedureNameIndexScan>, cc_tupdesc = 0x81f03f8, 
  id = 8, cc_ntup = 0, cc_maxtup = 300, cc_nkeys = 3, cc_size = 500, cc_key
= {
    1, 7, 10, 0}, cc_klen = {32, 2, 32, 0}, cc_skey = {{sk_flags = 0, 
      sk_attno = 1, sk_procedure = 62, sk_func = {
        fn_addr = 0x815bbb0 <nameeq>, fn_plhandler = 0, fn_oid = 62, 
        fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0, 
      sk_attno = 7, sk_procedure = 63, sk_func = {
        fn_addr = 0x8158c60 <int2eq>, fn_plhandler = 0, fn_oid = 63, 
        fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0, 
      sk_attno = 10, sk_procedure = 683, sk_func = {fn_addr = 0, 
        fn_plhandler = 0, fn_oid = 683, fn_nargs = 0}, sk_nargs = 0, 
      sk_argument = 0}, {sk_flags = 0, sk_attno = 0, sk_procedure = 0, 
      sk_func = {fn_addr = 0, fn_plhandler = 0, fn_oid = 0, fn_nargs = 0}, 
      sk_nargs = 0, sk_argument = 0}}, cc_next = 0x8213a78, 
  cc_lrulist = 0x82153d8, cc_cache = {0x8215d10, 0x8215d18, 0x8215d20, 
    0x8215d28, 0x8215d30, 0x8215d38, 0x8215d40, 0x8215d48, 0x8215d50,
...

I am surprised that  cache->cc_skey contains an addr and a number of
arguments in sk_func for each function except 683 that causes the error
message. 

Michael
-- 
Michael Meskes			meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Thu, 20 Aug 1998 09:24:31 +0200
Michael Meskes <meskes@online-club.de>
initdb problem again
What bugs me is how the initdb and regression tests can run fine on
BSDI, but fail other places.

> Maybe someone gets an idea by looking at the stack trace at the moment of
> the error message:
> 
> (gdb) where
> #0  fmgr_info (procedureId=683, finfo=0x82154f4) at fmgr.c:179
> #1  0x8162739 in CatalogCacheInitializeCache (cache=0x8215478, 
>     relation=0x81f03b0) at catcache.c:217
> #2  0x8163e3a in SearchSysCache (cache=0x8215478, v1=135759431, v2=1, 
>     v3=3221222512, v4=0) at catcache.c:837
> #3  0x8169076 in SearchSysCacheTuple (cacheId=8, key1=135759431, key2=1, 
>     key3=3221222512, key4=0) at syscache.c:508
> #4  0x8096869 in TypeCreate (typeName=0x82136a0 "pg_inherits", 
>     relationOid=16536, internalSize=4, externalSize=4, typeType=99 'c', 
>     typDelim=44 ',', inputProcedure=0x8178647 "int4in", 
>     outputProcedure=0x817863f "int4out", receiveProcedure=0x8178647 "int4in", 
>     sendProcedure=0x817863f "int4out", elementTypeName=0x0, 
>     defaultTypeValue=0x817863d "-", passedByValue=1 '\001', alignment=105 'i')
>     at pg_type.c:408
> #5  0x808e7ec in addNewRelationType (typeName=0x82136a0 "pg_inherits", 
>     new_rel_oid=16536) at heap.c:724
> #6  0x808e8c9 in heap_create_with_catalog (relname=0x82136a0 "pg_inherits", 
>     tupdesc=0x82137a8, relkind=114 'r') at heap.c:798
> #7  0x8089fae in Int_yyparse () at bootparse.y:182
> #8  0x808c4d4 in BootstrapMain (argc=6, argv=0xbffffb18) at bootstrap.c:426
> #9  0x80c8103 in main (argc=7, argv=0xbffffb14) at main.c:100
> 
> The structure cache points to starts with:
> 
> $7 = {relationId = 1255, indexId = 0, cc_relname = 0x819d780 "pg_proc", 
>   cc_indname = 0x819d760 "pg_proc_proname_narg_type_index", 
>   cc_iscanfunc = 0x8092760 <ProcedureNameIndexScan>, cc_tupdesc = 0x81f03f8, 
>   id = 8, cc_ntup = 0, cc_maxtup = 300, cc_nkeys = 3, cc_size = 500, cc_key
> = {
>     1, 7, 10, 0}, cc_klen = {32, 2, 32, 0}, cc_skey = {{sk_flags = 0, 
>       sk_attno = 1, sk_procedure = 62, sk_func = {
>         fn_addr = 0x815bbb0 <nameeq>, fn_plhandler = 0, fn_oid = 62, 
>         fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0, 
>       sk_attno = 7, sk_procedure = 63, sk_func = {
>         fn_addr = 0x8158c60 <int2eq>, fn_plhandler = 0, fn_oid = 63, 
>         fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0, 
>       sk_attno = 10, sk_procedure = 683, sk_func = {fn_addr = 0, 
>         fn_plhandler = 0, fn_oid = 683, fn_nargs = 0}, sk_nargs = 0, 
>       sk_argument = 0}, {sk_flags = 0, sk_attno = 0, sk_procedure = 0, 
>       sk_func = {fn_addr = 0, fn_plhandler = 0, fn_oid = 0, fn_nargs = 0}, 
>       sk_nargs = 0, sk_argument = 0}}, cc_next = 0x8213a78, 
>   cc_lrulist = 0x82153d8, cc_cache = {0x8215d10, 0x8215d18, 0x8215d20, 
>     0x8215d28, 0x8215d30, 0x8215d38, 0x8215d40, 0x8215d48, 0x8215d50,
> ...
> 
> I am surprised that  cache->cc_skey contains an addr and a number of
> arguments in sk_func for each function except 683 that causes the error
> message. 
> 
> Michael
> -- 
> Michael Meskes			meskes@online-club.de, meskes@debian.org
> Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Thu, 20 Aug 1998 14:04:00 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem again